[git-users] Use git on microsoft words documents
Hi, Is it possible to use git to manage microsoft documents? We have so many files and we need to manage the version, change, languages, etc management. Can we use git? Thanks. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Restrict users from creating or deleting the remote branches
Hi All, Being a GIT Admin, I need to know how to restrict the users from creating a new branch or deleting an existing branch in GIT Remote server. Please help me on this regard. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Help with git reset, please.
Michael writes: >> those two sentences say the same thing. HEAD *is* "the branch tip pointer", >> unless it's detached. > > Alright, maybe this is my first point of confusion. > > I thought "HEAD" is where you are at -- which of those letters you are > pointing to. > And, it may also be where a branch tip is pointing. > > If I make a commit while on a branch, then HEAD -- which letter I'm at > -- updates, and the branch tip pointer also updates. > > If I'm detached, then which letter I'm at updates, but the branch tips do not. > > Based on that, I thought that "git reset --soft" would change which > letter I'm pointing at, and leave the branch pointers unchanged. Your terminology is hard to follow here. There are two situations: 1) Normally, HEAD is (effectively) a symlink to one of the branch names, which in turn points to a commit. If you git-commit, the index contents are used to make a new commit, that commit's parent is the commit pointed by the branch name that is the target of HEAD, and that branch name is updated to the new commit (and so HEAD also points to that commit, in two steps). 2) A detached HEAD is a pointer to a commit. Creating a new commit does a similar this as in (1), but only HEAD is updated. "git reset --soft" changes what branch name HEAD links to. But here, to get to the bottom of the problem, please construct a reproducible example of it, using only command-line operations. Then we can tell exactly what you did (with no possibility that you make a mistake in describing it), and reproduce it ourselves. IIRC, "git log --graph" can show the history of may branches. Dale -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Help with git reset, please.
On Wed, 13 May 2015 08:29:39 -0700 Michael wrote: [...] > Alright, maybe this is my first point of confusion. > > I thought "HEAD" is where you are at -- which of those letters you > are pointing to. And, it may also be where a branch tip is pointing. > > If I make a commit while on a branch, then HEAD -- which letter I'm > at -- updates, and the branch tip pointer also updates. > > If I'm detached, then which letter I'm at updates, but the branch > tips do not. That is correct. > Based on that, I thought that "git reset --soft" would change which > letter I'm pointing at, and leave the branch pointers unchanged. No. That would not update a branch pointer only if you would be in a detached HEAD state: in that case just the HEAD would be updated. > What you seem to be saying, if I understand correctly, is that being > at a branch tip does not mean, "I am pointing to a letter, and the > branch tip is here as well", but "I am pointing at a branch tip, and > the branch tip is currently here". Well, I reckon the key to understand why these things work as they do in Git is to grasp the concepts of "refs" and how is the HEAD ref is special. As you supposedly know, a ref (short for "reference") is *a name* which points at "something which can be resolved to a commit" (Git manuals neatly refer to those "somethings" using the term "commit-ish"). Refs have type, and there are two types: heads and tags. Most people call heads branches, and the main Git command to manipulate heads is called `git branch` as well. Sure, this adds to the confusion but oh well. "Heads" is a somewhat better name because it underlines that branches in Git are mere pointers to commits, and commits do not have special properties which make them "belong" to a branch (as they do in Mercurial), and branches in Git can't have multiple heads (as they do in Mercurial). Okay, the next thing to understand is that head refs in Git can be of two kinds: "direct" (or "simple" or "normal" -- you name it) refs point directly to a commit using the SHA-1 name of it. A file representing such a ref merely contains those 40 ASCII characters of the SHA-1 name it points to. Another kind of a head ref is "symbolic": such a ref contains a reference to another ref by including a line of the form: ref: refs// Normal branches are direct refs, and that's why a branch is said to be a pointer to a commit. The ref named "HEAD" is special because it can be either a direct ref or a symbolic ref. If you check out a branch, HEAD becomes a symbolic ref pointing at that branch. If you check out something which can't be moved by committing, HEAD becomes a direct ref. I'm sure you can now see that the current kind of the HEAD ref precisely defines whether you're in a "detached HEAD" state or not. Consequently, the rules of how operations on HEAD behave depend on its current kind: when Git tries to reach for a commit through that ref, it either does this right away -- if HEAD is direct, -- or has to *dereference* this ref first -- if HEAD is symbolic. Now observe, that when you call `git reset --soft|--mixed|--hard` while you have a branch checked out (and HEAD is symbolic) Git chases the chain of HEAD -> branch and changes the ref representing a branch. Note that HEAD in this case is not really changed at all! It just still points to the same ref as before, just that ref got updated. Conversely, in a detached HEAD state, `git reset ...` above operates on the HEAD ref directly (there's nowhere to resolve it) and moves it directly. > If that is the case, then the first thing I would need to do to make > "git reset --soft" behave the way I think it does is to first go to > detached head at the same letter (so I am now pointing at the letter > that the branch tip points to, rather than pointing to the branch tip > pointer), then I can move head without moving branch tips. That is correct. The question is: do you really need to do this? I'd say bringing just a single file from a dirty devel branch onto master could be done way simpler (see below). [...] > Now, lets say your topic branch is really, really messy, with lots of > commits, tests, commits, tests, undo, test, change, test, repeat. And > I really don't want to toss that in as a fast forward. And, > apparently, using "no-ff" breaks bisect and blame (1). That means > either a squash commit (which I've managed to mess up once in two > uses), or something else. As this was just a single file, I thought > this would be a simple way to move one file cleanly onto master. The question is: is it okay for you to make all the changes made to that file appear as a single commit on master? If the answer is yes, then: $ git checkout master $ git checkout devel path/to/the/file $ git add -u The second command will update the specified file with its content it currently has at the "devel" branch. So the only thing left is to add the new contents of the file to the index and commit. If the answer
Re: [git-users] Help with git reset, please.
On 2015-05-13, at 7:54 AM, Roman Neuhauser wrote: > # keybou...@gmail.com / 2015-05-13 07:37:34 -0700: >>> These modes are selected by a special command line option: --soft, >>> --hard or --mixed, with the latter being the default. >>> >>> The --soft option only repositions the branch's tip, >> >> This is problem number one. That's pretty much what happened -- the >> branch ("animalAging") was reset, but the documentation ("man >> git-reset") claims something else. >> >> --soft >> Does not touch the index file or the working tree at all >> (but resets the head to , just like all modes do). >> This leaves all your changed files "Changes to be committed", >> as git status would put it. > > i don't see any disagreement there. > >> It reset the head to commit, yes. >> It also reset the branch tip pointer. > > those two sentences say the same thing. HEAD *is* "the branch tip pointer", > unless it's detached. Alright, maybe this is my first point of confusion. I thought "HEAD" is where you are at -- which of those letters you are pointing to. And, it may also be where a branch tip is pointing. If I make a commit while on a branch, then HEAD -- which letter I'm at -- updates, and the branch tip pointer also updates. If I'm detached, then which letter I'm at updates, but the branch tips do not. Based on that, I thought that "git reset --soft" would change which letter I'm pointing at, and leave the branch pointers unchanged. What you seem to be saying, if I understand correctly, is that being at a branch tip does not mean, "I am pointing to a letter, and the branch tip is here as well", but "I am pointing at a branch tip, and the branch tip is currently here". If that is the case, then the first thing I would need to do to make "git reset --soft" behave the way I think it does is to first go to detached head at the same letter (so I am now pointing at the letter that the branch tip points to, rather than pointing to the branch tip pointer), then I can move head without moving branch tips. >> I found out about the --soft option by asking this list, how do I >> change where a commit will go without altering any of my files -- I've >> got files on branch X, but they should actually go onto master. > > that depends on your topology. let's say you've got master at C, > topic at F: > > A -- B -- C >\ > D -- F > > % git checkout master > > % git merge --ff-only topic > # OR > % git reset --hard topic > > if this is your topology: > > A -- B -- C >\ > D -- F > > % git checkout topic > % git rebase master > > that will give you the above, linear topology and you can apply the > same commands. Now, lets say your topic branch is really, really messy, with lots of commits, tests, commits, tests, undo, test, change, test, repeat. And I really don't want to toss that in as a fast forward. And, apparently, using "no-ff" breaks bisect and blame (1). That means either a squash commit (which I've managed to mess up once in two uses), or something else. As this was just a single file, I thought this would be a simple way to move one file cleanly onto master. Also: Every tutorial on branching I've seen says to branch from as far back in history as makes sense; what you said seems to be the opposite, branch from the tip of history, not from back in history. What am I misunderstanding? --- Meanwhile, got any user-friendly tutorials on the proper use of rebase? (1): Understanding git workflow: https://sandofsky.com/blog/git-workflow.html > -- > roman --- Entertaining minecraft videos http://YouTube.com/keybounce -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Help with git reset, please.
# keybou...@gmail.com / 2015-05-13 07:37:34 -0700: > > These modes are selected by a special command line option: --soft, > > --hard or --mixed, with the latter being the default. > > > > The --soft option only repositions the branch's tip, > > This is problem number one. That's pretty much what happened -- the > branch ("animalAging") was reset, but the documentation ("man > git-reset") claims something else. > >--soft >Does not touch the index file or the working tree at all > (but resets the head to , just like all modes do). >This leaves all your changed files "Changes to be committed", >as git status would put it. i don't see any disagreement there. > It reset the head to commit, yes. > It also reset the branch tip pointer. those two sentences say the same thing. HEAD *is* "the branch tip pointer", unless it's detached. > I found out about the --soft option by asking this list, how do I > change where a commit will go without altering any of my files -- I've > got files on branch X, but they should actually go onto master. that depends on your topology. let's say you've got master at C, topic at F: A -- B -- C \ D -- F % git checkout master % git merge --ff-only topic # OR % git reset --hard topic if this is your topology: A -- B -- C \ D -- F % git checkout topic % git rebase master that will give you the above, linear topology and you can apply the same commands. -- roman -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Help with git reset, please.
> > Well, `git reset` is completely documented in its manual page > (try running `git help reset`). I did. But ... > These modes are selected by a special command line option: --soft, > --hard or --mixed, with the latter being the default. > > The --soft option only repositions the branch's tip, This is problem number one. That's pretty much what happened -- the branch ("animalAging") was reset, but the documentation ("man git-reset") claims something else. --soft Does not touch the index file or the working tree at all (but resets the head to , just like all modes do). This leaves all your changed files "Changes to be committed", as git status would put it. It reset the head to commit, yes. It also reset the branch tip pointer. I found out about the --soft option by asking this list, how do I change where a commit will go without altering any of my files -- I've got files on branch X, but they should actually go onto master. (I am trying very, very hard to follow what seems to be the consistent recommendation -- your work branches can and should be messy, but what you put onto master should be clean, either by squashing a bunch of commits, or using the branches as temporaries for testing purposes.) > 1. http://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified > 2. http://threetrees.herokuapp.com/ Thank you. --- Entertaining minecraft videos http://YouTube.com/keybounce -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Help with git reset, please.
On Tue, 12 May 2015 20:34:01 -0700 Michael wrote: [...] > I'm just not understanding the git reset -- it seems to not just > change the active branch, and possibly the working tree/cached for > commit, but also alters where branch label point. > > That seems to be non-documented, and ... confusing. Well, `git reset` is completely documented in its manual page (try running `git help reset`). The problem with this command is that it gathers several modes of operation under the same name. The general distinction is this: * Two ways to call `git reset` make it to do a job essentially reverse to that of `git add`. In this mode, `git reset` operates on the index only. These two ways to call `git reset` are: git reset foo.js to unstage the changes made to foo.js and added to the index by calling `git add foo.js`. In more strict terms, this command sets the index entry for the file foo.js to the contents it has at the HEAD revision. You can specify a revision other than HEAD, if you want. You can specify several files as well. git reset --patch foo.js Runs you through an interactive hunk-by-hunk "unstaging" which is just like `git add --patch foo.js` but it removes the hunks from the index rather than adding them. This command can be run with no files specified and then it works on the whole index. * Anothe three ways to call `git reset` affect the currently checked out branch and possibly also the index and the work tree -- that's why there are three of them. These modes are selected by a special command line option: --soft, --hard or --mixed, with the latter being the default. The --soft option only repositions the branch's tip, the --mixed option performs what the --soft does and also resets the index to match the new tip. --hard does everything --mixed does and also resets the work tree to match the new content of the index. All this is documented in the manual page but the manual is, well, a manual -- it's for strictly documenting, not for explaining from a general standpoint -- that's what books and tutorials are for. Hence I recommend you [1] and [2] to grasp the concepts in a non-manual way. 1. http://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified 2. http://threetrees.herokuapp.com/ -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Re: Trouble with the git-http-backend; Documentation unprecise
On Tue, 12 May 2015 00:43:14 -0700 (PDT) Matthias Lantsch wrote: > I'm sorry I forgot about the most important part: > setting the pth variable for the PATH_INFO > $pth = explode(GIT_DOCUMENT_ROOT, isset($_SERVER > ['REDIRECT_URL']) ? $_SERVER['REDIRECT_URL'] : '', 2); > $pth = array_pop($pth); One problem with the way you're communicating your difficulties with us is that you imply everyone is fluent in PHP, which is just wrong ;-) -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Trouble with the git-http-backend; Documentation unprecise
On Tue, 12 May 2015 00:40:13 -0700 (PDT) Matthias Lantsch wrote: > I usually always try to solve problems myself, but I really have > gotten onto my limits with this. > Situation: > I am trying to create a php "glue" script between apache and the git > http backend in order to allow myself to hook into all git processes > via my php framework [...] > To make sure that the problem lies not with the server setup, I have > executed tests on 2 different linux machines as well as a windows > machine. I was testing with a bare repository, which I added a single > file to over local push (file://). > GIt update-server-info was executed as well. > But I always get the message: > warning: You appear to have cloned an empty repository. > Checking connectivity... done. > And in my apache error log: > fatal: 'test.git/info/refs': aliased\n [...] I reckon this might be the root of your problem. Can you start with plain apache setup which works, and then transition to your solution? To be more clear, the basic idea of setting up Apache to be a front-end to Git is somehow make sure that some common prefix on your designated virtual host (or the default host, if applies) is defined to be a script alias to the git-http-backend binary. That is, something like: ServerName git.domain.local ServerAlias git DocumentRoot /srv/git ScriptAlias / /usr/lib/git-core/git-http-backend/ # Access control directives etc... # Maybe also SetEnv GIT_PROJECT_ROOT /srv/git Once you have this working, replace the real git-http-backend with your custom wrapper and have it done. The git-http-backend manual page contains extensive examples, including a way to make Apache serve certain static files directly (using sendfile(2) on Linux and whatnot) rather than through the backend. To recap, I'd work piecemeal: first get Git http backend working along with your front-end and only then plug your PHP framework in place of the backend, wrapping it. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.