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

[Andrew Wong <andrew.kw.w@gmail.com>]

On Wed, Feb 26, 2014 at 1:21 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> 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. 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 ;-).

I don't think it's actually dropping data though, because your changes just
come from "git merge". So you can also do the merge again.

To examine the changes, you're saying you'd do "git reset && git diff". But
without doing "git reset", couldn't you do "git diff HEAD" to get the diff?
This also has the advantage of keeping git in the merging state, so you can
decide to continue/abort the merge later on.

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

Yeah, this breaks compatibility, but like I said, during a merge, I don't
see a good reason to do "git reset --mixed", and not "git reset --merge".
Especially when there are local changes, "--mixed" would actually cause
more headaches than "git reset --merge", because you would lose the
distinction between merge changes and unstaged changes.

Andrew