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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Sep 9, 2013, 23:17 UTC
Message-ID: <CAMP44s0YaQo7xAkPcV3xVTcYQStUVuyY=we-=KMgtZ-xgZzz1Q@mail.gmail.com>
In-Reply-To: <vpqr4cy4g5q.fsf@anie.imag.fr>

On Mon, Sep 9, 2013 at 2:18 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Show 18 quoted lines

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

Show 5 quoted lines

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

Show 7 quoted lines

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

Show 9 quoted lines

> 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