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

Re: [PATCH v2 2/4] Documentation: warn prominently against merging with dirty trees

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 11, 2010, 02:30 UTC
Message-ID
<7vzl4lbcfl.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20100111021322.GA8480@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 5 quoted lines
> Here is a scenario I worry about:
>
> Suppose I have a change to main.c staged, to add a feature that others
> have discussed as well.  After a short distraction, I return and run
> ‘git pull’ to see what upstream has been working on.

If your index is dirty, any "mergy" operation will refuse to work *before* touching anything, so you won't use "git reset --merge" to begin with.

You are allowed to have local modifications only in your work tree. Furthermore, even git experts limit them to something they feel they can afford to lose and recreate easily if necessary. See for example:

  http://thread.gmane.org/gmane.comp.version-control.git/15148/focus=15476
That is why I said:
  Of course, the user needs to understand what he or she is doing (see
  http://thread.gmane.org/gmane.comp.version-control.git/136166/focus=136171
  for example).  And that is one reason we (at least I) try to teach new
  people to start working from a clean tree, until they get comfortable
  working with mergy operations.
and that is why the archived article referenced above refers to
  http://gitster.livejournal.com/29060.html

You need to be able to tell the two ways in which a "mergy" operation can "fail" apart [*1*].

 - One that stops before touching anything (either your index was dirty
   and nothing happened, or your index was clean but you had local
   modifications in your work tree).  You do not run "git reset --merge",
   for this one; and
 - Another that goes ahead and results in conflicts.  When you got these
   conflicts, you can "reset --merge" them away.
[Footnote]

*1* Strictly speaking, the latter is not even a "failure"; it allowed you to make progress, merging all the auto-mergeable parts without your help, and only asking you to handle the remainder.

Previous: Jonathan NiederNext: Jonathan Nieder
Message 17 of 46 in “Documentation/git-merge: reword references to "remote" and "pull"”
  1. 1/2 Documentation/git-merge: reword references to "remote" and "pull"Thomas Rast, Jan 7, 2010
  2. 2/2 Documentation: warn prominently against merging with dirty treesThomas Rast, Jan 7, 2010
  3. 3/2 Documentation/git-merge: format full commands in typewriter fontThomas Rast, Jan 7, 2010
  4. Jonathan NiederJan 7, 2010
  5. Junio C HamanoJan 7, 2010
  6. Junio C HamanoJan 7, 2010
  7. 0/4 Documentation style fixesThomas Rast, Jan 10, 2010
  8. 1/4 Documentation/git-merge: reword references to "remote" and "pull"Thomas Rast, Jan 10, 2010
  9. Jonathan NiederJan 10, 2010
  10. Thomas RastJan 10, 2010
  11. Documentation: merge: use MERGE_HEAD to refer to the remote branchJonathan Nieder, Jan 23, 2010
  12. 2/4 Documentation: warn prominently against merging with dirty treesThomas Rast, Jan 10, 2010
  13. Jonathan NiederJan 10, 2010
  14. Junio C HamanoJan 10, 2010
  15. Thomas RastJan 10, 2010
  16. Jonathan NiederJan 11, 2010
  17. Junio C HamanoJan 11, 2010
  18. Jonathan NiederJan 11, 2010
  19. 0/6 Re: Documentation: warn prominently against merging with dirty treesJonathan Nieder, Jan 11, 2010
  20. 1/6 Documentation: clarify one-line description for mergeJonathan Nieder, Jan 11, 2010
  21. 2/6 Documentation: merge: add an overviewJonathan Nieder, Jan 11, 2010
  22. Junio C HamanoJan 11, 2010
  23. 4/6 Documentation: emphasize when git merge terminates earlyJonathan Nieder, Jan 11, 2010
  24. Thomas RastJan 11, 2010
  25. 5/6 Documentation: merge: add a section about fast-forwardJonathan Nieder, Jan 11, 2010
  26. 6/6 Documentation: tweak How Merge WorksJonathan Nieder, Jan 11, 2010
  27. Thomas RastJan 11, 2010
  28. Petr BaudisJan 13, 2010
  29. Junio C HamanoJan 13, 2010
  30. 3/4 Documentation: format full commands in typewriter fontThomas Rast, Jan 10, 2010
  31. Jonathan NiederJan 10, 2010
  32. Thomas RastJan 10, 2010
  33. Thomas RastJan 10, 2010
  34. Junio C HamanoJan 10, 2010
  35. Thomas RastJan 10, 2010
  36. 1/2 More missed dashed 'git-cmd' formsThomas Rast, Jan 10, 2010
  37. 2/2 More missed `code snippets`Thomas Rast, Jan 10, 2010
  38. Documentation: show-files is now called git-ls-filesThomas Rast, Jan 10, 2010
  39. Junio C HamanoJan 18, 2010
  40. Thomas RastJan 19, 2010
  41. Jonathan NiederJan 19, 2010
  42. Junio C HamanoJan 10, 2010
  43. Jonathan NiederJan 10, 2010
  44. 1/2 Documentation: git gc packs refs by default nowJonathan Nieder, Jan 10, 2010
  45. 2/2 Documentation: tiny git config manual tweaksJonathan Nieder, Jan 10, 2010
  46. Thomas RastJan 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.