Junio C Hamano wrote:
> 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~3
True. (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.)
> 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".
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html