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, 14:13 UTC
Message-ID: <858usvz5nj.fsf@stephe-leake.org>
In-Reply-To: <87fvn335sm.fsf@fencepost.gnu.org>

David Kastrup <dak@gnu.org> writes:

Show 8 quoted lines

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> I like commands that "do the right thing". So no, this would not be
>> confusing.
>
> I _hate_ commands that think they know better than to do what they are
> told.  In particular when doing destructive things.  And just because
> _you_ like them does not mean they are not confusing.

Ok, I should have said "not confusing for me".

People differ.

> In the long run, it is much more confusing if you come to rely on some
> commands doing "the right thing" while in other cases, the actually
> written thing is done.

There should always be the option of telling git exactly what to do. In my emacs front end, the command that "does the right thing" is _called_ "do-the-right-thing". All of the other commands do exactly as told.

In this case, it is only "git reset" that would do the right thing, since you did _not_ tell it specifically what to do.

Relying on a default is always problematic, in my experience; I much prefer "no default" to "a default that people voted on 10 years ago, and now we are stuck with it".

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

-- 
-- Stephe