git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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~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.)
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.

Previous: Junio C HamanoNext: Junio C Hamano
Message 29 of 38 in “Black smoke from git rebase -i exec”
  1. Ævar Arnfjörð BjarmasonAug 10, 2010
  2. Matthieu MoyAug 10, 2010
  3. Ævar Arnfjörð BjarmasonAug 10, 2010
  4. Johannes SixtAug 10, 2010
  5. Ævar Arnfjörð BjarmasonAug 10, 2010
  6. Matthieu MoyAug 10, 2010
  7. 1/2 rebase -i: add exec command to launch a shell commandMatthieu Moy, Aug 10, 2010
  8. Junio C HamanoAug 11, 2010
  9. Matthieu MoyAug 12, 2010
  10. 0/2 rebase -i: in-editor documentation nitsJonathan Nieder, Jan 16, 2011
  11. 1/2 rebase -i: reword in-editor documentation of "exec"Jonathan Nieder, Jan 16, 2011
  12. Matthieu MoyJan 16, 2011
  13. Junio C HamanoJan 18, 2011
  14. Jonathan NiederJan 20, 2011
  15. Junio C HamanoJan 20, 2011
  16. 1/2 rebase -i: clarify in-editor documentation of "exec"Jonathan Nieder, Jan 21, 2011
  17. Matthieu MoyJan 21, 2011
  18. Jonathan NiederJan 21, 2011
  19. Matthieu MoyJan 21, 2011
  20. 2/2 rebase -i: explain how to discard all commitsJonathan Nieder, Jan 16, 2011
  21. 2/2 Re: rebase -i: explain how to discard all commitsNicolas Sebrecht, Jan 20, 2011
  22. Jonathan NiederJan 20, 2011
  23. 2/2 Re: rebase -i: explain how to discard all commitsNicolas Sebrecht, Jan 20, 2011
  24. Thomas RastJan 20, 2011
  25. Junio C HamanoJan 20, 2011
  26. Johannes SchindelinJan 21, 2011
  27. Documentation: suggest "reset --keep" to undo a commitJonathan Nieder, Jan 21, 2011
  28. Junio C HamanoJan 21, 2011
  29. Jonathan NiederJan 21, 2011
  30. Junio C HamanoJan 21, 2011
  31. Junio C HamanoJan 21, 2011
  32. Matthieu MoyJan 21, 2011
  33. Joshua JensenJan 21, 2011
  34. Documentation: do not treat reset --keep as a special caseJonathan Nieder, Jan 21, 2011
  35. Junio C HamanoJan 21, 2011
  36. Jay SoffianJan 26, 2011
  37. Johannes SchindelinJan 23, 2011
  38. 2/2 test-lib: user-friendly alternatives to test [-d|-f|-e]Matthieu Moy, Aug 10, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.