Re: [git-users] Help with git reset, please.
On Tue, 12 May 2015 20:34:01 -0700 Michael keybou...@gmail.com 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] 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 commit, 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 commit, 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 2015-05-13, at 7:54 AM, Roman Neuhauser neuhau...@sigpipe.cz 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 commit, 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.
On Wed, 13 May 2015 08:29:39 -0700 Michael keybou...@gmail.com 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/type/refname 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 is no, things are harder. A squash
Re: [git-users] Help with git reset, please.
Michael keybou...@gmail.com 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.
Michael keybou...@gmail.com writes: keybounceMBP:config michael$ git commit -m First test [animalAging 0653a0b] First test 1 file changed, 140 insertions(+) create mode 100644 HarderWildlife.cfg keybounceMBP:config michael$ gitk --all ^C keybounceMBP:config michael$ git commit HarderWildlife.cfg -m Works good enough. Mod updated. [animalAging 3d5c944] Works good enough. Mod updated. 1 file changed, 20 insertions(+), 2 deletions(-) ## At this point, I have committed my first edits, from the index, verified that it was in, ## and then committed the final file, with the additions from the new version of the program. keybounceMBP:config michael$ git reset --soft master ## I am trying to take this config file, as-is, to put into master, to keep the master branch ## clean (while using the topic branch for development work) keybounceMBP:config michael$ gitk --all ## But ... my last two commits do not show up at all??? What branch was checked out when you did those two commits? If I read the output of git-commit correctly, the branch was anamalAging. But the git-reset changed the checked out branch to master, which of course, did not show the commits made on another branch. 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.
