Felipe Contreras <felipe.contre...@gmail.com> writes:

> On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson
> <sand...@crustytoothpaste.net> wrote:
>> Yes, that would be me.  My hesitance here is that as the one usually
>> driving git updates (which so far have happened once a year), I will end
>> up retraining forty developers.  I don't think the current behavior is
>> broken or really problematic at all: merging has always been the
>> default, and people have come to expect that.
> It may not be broken for you, but it is for other people. Would you be
> so egocentric as to ignore everybody else because "it works for you"?

It's not a matter of "works for me". Git currently "works" for all use
cases because you can already merge or rebase. The proposed changes are
not about allowing the behavior that works, but disallowing the behavior
that doesn't.

I agree that allowing people to reject non-ff merge is a good idea.

I strongly disagree that this should eventually become the default,
though. I think it should really remain an opt-in (possibly with some
non-scary warning advertizing for the feature).

First, the discussions on this thread show that it's hard to find the
right behavior. My guess is that it's hard because we're trying to think
for the users. I've used GNU Arch for a while, and this VCS was trying
to impose what the developer thought was good for me. I had to fight
with the tool whenever I tried to do something "non-standard". I don't
want to go back there. Preventing _users_ to do something because _we_
considered it was bad for them is wrong IMHO.

I already mentionned another reason in
http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=229162 :
"git rebase" is hard to use for many people. With "git merge", doing
things wrong isn't so bad. If you forget to commit after a conflicted
merge, you'll mix your changes with the merge, this is bad, but it
works. With "git rebase", if you forget to "git rebase --continue" after
a conflict, you end up in detached HEAD, with part of your own changes
discarded. If my students end up in this situation, they'll stop using
Git and exchange files by email.

"git pull" is one of the first things one learns with Git, and
_requiring_ users to chose between merge and rebase is a nonsense at
this time of learning.

Matthieu Moy
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to