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

[Junio C Hamano <gitster@pobox.com>]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Andrew Wong <andrew.kw.w@gmail.com> writes:
>
>> 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.