Re: [RFC 0/3] Make git more user-friendly during a merge conflict

From: Stephen Leake <stephen_leake@stephe-leake.org>
Date: Feb 28, 2014, 17:26 UTC
Message-ID: <85zjlb1740.fsf@stephe-leake.org>
In-Reply-To: <87txbj1fnw.fsf@fencepost.gnu.org>

David Kastrup <dak@gnu.org> writes:

Show 14 quoted lines

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> "do the right thing" commands also tend to do the wrong thing
>>> occasionally with potentially disastrous results when they are used
>>> in scripts where the followup actions rely on the actual result.
>>
>> That is bad, and should not be allowed. On the other hand, I have yet
>> to see an actual use case of bad behavior in this discussion.
>
> Huh.
>
> <http://permalink.gmane.org/gmane.comp.version-control.git/242744>

That's about backward incompatibility, which is bad, but not what I was talking about above.

Specifically, the proposed change is:

'git reset' will have different default actions depending on context:

- if a merge is not in progress, it will do 'git reset --mixed'

- if a merge is in progress, it will do 'git reset --merge'

Is there a use case where this will do the wrong thing?

Of course, I fully understand that not being able to come up with a "wrong thing" use case is not the same as proving it cannot happen, especially for a system as complex as git.

So it would be ok to say "we don't do that so we are not exposed to unintended consequences".

But "wrong thing" use cases are more convincing :).

-- 
-- Stephe