Re: [PATCH] Documentation: suggest "reset --keep" to undo a commit
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Jan 21, 2011, 19:14 UTC
- Message-ID
- <20110121191459.GC16325@burratino>
- In-Reply-To
- <7voc7ap3dp.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
Show 11 quoted lines
> But the user could do the reviewing and thinking with some local changes > still in the working tree (they are incredients for the fourth commit yet > to be made) and decide to branch at that point. The description in <1> > needs to be updated to hint that there can be uncommitted changes, e.g. > > You have worked for some time, made a few commits, and may have > uncommitted changes. After reviewing the current state, you > realized that ... > > Using --keep may help the user do so, but only if the local changes do not > conflict with the changes in the recent commits to be discarded, right?
I think this explanation misses out on something.
I may be abusing git in a certain way, but I find myself in the following situation fairly often:
... hack hack hack ... git add -p; # hmm, looks like multiple features. git stash -k ... test ... git commit; # commit feature #1 git stash pop
git add -p git stash -k ... test ... git commit; # commit feature #2 git stash pop
# hmm, feature #2 is not suitable for this branch. git branch wip/feature-2 git reset --keep HEAD^; # <*> git add -p git stash -k ... test ... git commit; # commit feature #3
On line <*>, I am just not thinking about the uncommitted changes. They may be there or they may not. If they are in the way of what I am trying to do, "git reset --keep" will politely inform me so I can act accordingly (usually stash, commit, or discard them).
> By the way, a more natural way to do this would actually be:
>
> $ git checkout -b topic/wip
> $ git branch -f @{-1} HEAD~3True. (I think the intended scenario was
git branch topic/wip; # save the tip for later git reset --keep HEAD~3 # now what was I working on? ... hack hack hack ...
# okay, now we have time for that diversion. git checkout topic/wip
but it would be nice to contrast it with the one you described.)
Show 7 quoted lines
> or using the stash: > > $ git stash ;# save local changes > $ git branch topic/wip ;# and mark the tip before rewinding > $ git reset --hard HEAD~3 ;# you could say --keep here too > $ git checkout topic/wip ;# and then continue > $ git stash pop ;# with the local changes
This approach leaves more files touched and more targets to be rebuilt by "make".
Show 6 quoted lines
> Please tell a story where keep makes more sense than hard by enhancing the > explanatory text <1> associated with this section. The current text says > that the three topmost commit representing what you have recently worked > so far are all unwanted, strongly hinting that hard is more appropriate > thing to do than keep, which is not what we want if we are changing the > example to use keep.
Maybe the best story would be "you have just explored a blind alley and decided the last three commits are not a good idea at all", with reference to a new section explaining that
* --soft is for when the commit in preparation has the right content but should be on top of a different parent (e.g., squashing commits)
* --keep is for transporting your local changes to a different commit (e.g., rewinding a branch or transplanting changes)
- --merge is a limited and low-level tool for recovering from a conflicted merge and most often will take ORIG_HEAD as its argument.
Maybe in the future merges will save more information so reset --merge can error out more often.
- --hard is for resetting to a known state
- --mixed is for resetting to a known state but leaving the worktree alone
> It would be sufficient to just hint that the uncommitted changes that you > have in your working tree are unrelated to what these three commits wanted > to do (e.g. you always keep small changes around, such as debugging > printf's
That use case is less interesting to me --- it is relatively harmless to clobber such content.