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

Junio C Hamano wrote:

Jonathan Nieder [off-list ref] writes:

quoted

Oh, that is a problem.  Maybe 'git merge' should refuse to merge
unless told otherwise, if there is a dirty index and there might be
conflicts.

"git reset --merge" will keep your local changes after such a merge, and
"mergy" operations (not just "merge" but also "revert", "am -3", etc)
won't get you into a situation where you cannot, by refusing to do
anything when e.g. your index is dirty.  Especially when Christian's
"reset --merge" update becomes solid, "... is hard to back out of" will
become a false statement.

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.  As luck would
have it, the remote version of main.c is exactly the same as my
modified version, so the merge happily proceeds.  Some other files
merge cleanly.  Eventually there is some conflict.

Now I regret the pull.  Will ‘reset --merge’ restore the index and
work tree to its original state?

If the change to main.c was _not_ staged, then the merge would have
failed early, so that is not something to worry about.

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

Agreed.  And probably the user who understands what is going on will
not make the mistake I described above.  Otherwise, they could succumb
to a related problem:

Suppose all is as above, except that git detects no conflict.  Suppose
further that some upstream commit was bogus.

Now I regret the pull.  How can I restore the index and work tree to
its original state?

If I reset --hard (or --merge) to the previous HEAD commit, the
modification to main.c is forgotten.  In practice, I would do
'git reset --hard HEAD^ && git checkout HEAD@{1} -- main.c'.