Re: [RFC 3/3] reset: Change the default behavior to use "--merge" during a merge

Matthieu Moy [off-list ref] writes:

Andrew Wong [off-list ref] writes:

quoted

If the user wants to do "git reset" during a merge, the user most likely
wants to do a "git reset --merge". This is especially true during a
merge conflict and the user had local changes, because "git reset" would
leave the merged changes mixed in with the local changes. This makes
"git reset" a little more user-friendly during a merge.

But this breaks backward compatibility.

I sometimes run "git reset" during a merge to only reset the index and
then examine the changes introduced by the merge.

Hmmmm, wouldn't it a better way to do this to run "git diff HEAD"
without any resetting of the index, though?  Having said that...

With your changes,
someone doing so would abort the merge and discard the merge resolution.

I very rarely do this, but even rarely, I wouldn't like Git to start
droping data silently for me ;-).

...this indeed may be a concern that deserves a bit more thought.

I'm not really convinced that this is such a good change, and if we go
this way, there should be a transition to let users stop using
argumentless "git reset" to reset the index during a merge.

If the only reason somebody might want to "reset --mixed" is to make
the next "git diff" behave as if it were "git diff HEAD", I would be
willing to say that we should:

 - start warning against "reset" (no mode specifier) and "reset --mixed"
   when the index is unmerged *and* MERGE_HEAD exists; and then

 - after a few releases start erroring out when such a "reset" is
   given; and then

 - use this patch to intelligently choose the default mode.

Another downside of "reset --mixed" during a conflicted merge (or
other mergy operations, e.g. "am -3") is that new files are left in
the working tree, making the next attempt to redo the mergy
operation immediately fail until you remove them, so in practice,
the only mode I'd use with a conflicted index (be it from a
conflicted merge or any other mergy operation) is "reset --hard".

So forbidding "reset --mixed" when the index is unmerged (even when
there is no MERGE_HEAD) may be a good idea in the long run.

On 02/26/14 15:53, Junio C Hamano wrote:

 - start warning against "reset" (no mode specifier) and "reset --mixed"
   when the index is unmerged *and* MERGE_HEAD exists; and then

Why do we also want to check if index is unmerged? This situation can
happen regardless of having conflicts or not (--no-commit, aborting the
editor, etc.). As long as the user is in the middle of a merge
(MERGE_HEAD exists), shouldn't they be warned if they used "git reset"?