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

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

Andrew Wong <andrew.kw.w@gmail.com> writes:

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

But you can't repeat your merge conflicts resolution.

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

I could. The point is, sometimes I don't.

If you were to design "git reset"'s interface from scratch, your
proposal would make sense. But we're talking about a change, and you
can't expect that users never use the current behavior. At the very
least, there should be a warning telling the user that the behavior
changed, and I'm really afraid that the warning goes along the lines of
"I've thought you'd prefer me to discard your unsaved changes, please
rewrite them if you actually didn't want me to".

>> 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",

The point with backward compatibility is not to know whether users have
a good reason to, but whether you can guarantee that no one ever does
it.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/