Re: [PATCH 0/3] Reject non-ff pulls by default

[Felipe Contreras <felipe.contreras@gmail.com>]

On Mon, Sep 9, 2013 at 2:18 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson
>> <sandals@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.

If it works for all use cases why are we discussing this?

Hint: because it 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).

That defeats the whole purpose of the proposal, which means that you
don't understand the problem.

The problem is the newcomers, and the newcomers will most definitely
not activate a configuration option to tell them that they are doing
something potentially undesirable.

By the time they learn about pull.mode, they probably already know
what a rebase is. So what is the point of the configuration in the
first place?

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

We are not preventing anybody from anything. The user can do 'git pull
--merge', the user can set 'pull.mode = merge', the user can do
anything he wants.

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

That doesn't mean anything, you are assuming the user will do 'git
pull --rebase', and there's no rationale as to why they would end up
doing that.

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

Let's use another core command as an illustration.

'git commit' by default "prevents" users from creating commits without
first adding changes to the staging area, and since it's a concept
unique to Git, it's fair to say that none of the newcomers understand
why 'git commit' is failing, the error messages is not particularly
useful either.

Following your rationale, by default 'git commit' should behave like
'git commit --all', and add all the changes in the work tree to the
new commit when there's no changes in the staging area, that would be
the easiest for the newcomers, but we don't do that, we "force" them
to understand what the staging area is, or do 'git commit --all', most
of the newcomers do the later.

So, if we draw a parallel with with pull, 'git pull --merge' is like
'git commit --all'; if they don't know what they are doing, that's
what they should type, and when the pull is non-fast-forward we error
out, just like we error out when there's nothing on the staging area.

-- 
Felipe Contreras