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

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

On Sun, Sep 8, 2013 at 1:54 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Sep 08, 2013 at 01:17:42AM -0500, Felipe Contreras wrote:
>
>> > I think it's fine to tell them to do "git pull --merge". What I'd worry
>> > more about is somebody who is suddenly presented with the choice between
>> > "--rebase" and "--merge" and doesn't know which to choose. We've created a
>> > cognitive load on the user, and even more load if they choose --rebase
>> > and don't quite understand what it means.
>>
>> If that happens they will go back to the guy that told them to run
>> those commands.
>
> I think "the guy" may be git itself. For example, here is a possible
> session with jc/pull-training-wheel:
>
>   $ git push

Who told him to use 'git push'? Certainly not git.

>   To ...
>    ! [rejected]        master -> master (non-fast-forward)
>   error: failed to push some refs to '...'
>   hint: Updates were rejected because the tip of your current branch is behind
>   hint: its remote counterpart. Integrate the remote changes (e.g.
>   hint: 'git pull ...') before pushing again.
>   hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>
>   $ git pull

>   The pull does not fast-forward; please specify
>   if you want to merge or rebase.
>
>   Use either
>
>       git pull --rebase
>       git pull --merge
>
>   You can also use 'git config pull.rebase true' (if you want --rebase) or
>   'git config pull.rebase false' (if you want --merge) to set this once for
>   this project and forget about it.

Why stop there? Post the whole man page already.

Moreover, it's overly verbose on all the wrong and irrelevant
information. If you are going to waste precious screen state, explain
wth a "non fast-forward" is; people can figure out what a merge is,
and maybe a rebase, but a "non fast-forward" definitely not.

> The user is pointed at "pull" from "push", and then gets presented with
> the "merge or rebase" choice. It may be that the advice you can find by
> googling "merge vs rebase" is enough to then help the person along
> (and/or we may need to improve the manpages in that respect).

Yes, but that's not the use-case we are talking about. You mentioned
specifically a "svn-like" worfklow where the guy was told by somebody
else to replace the svn commands with git ones.

If we are talking about a guy that is learning git, that's and
entirely different case.

> I am genuinely curious what people in favor of this feature would want
> to say in the documentation to a user encountering this choice for the
> first time. In my experience, rebasing introduces more complications,
> specifically:

Yes, but it's what the user might want.

> I know those are all balanced by some advantages of rebasing, but I also
> think they are things that can be troublesome for a user who does not
> fully grok the rebase process. I'm just wondering if we should mention
> both, but steer people towards merging as the safer alternative (you
> might have ugly history, but you are less likely to create a mess with
> duplicate commits or badly-resolved conflicts).

The purpose of this change in the code is not to change the user
behavior. The choice of merge vs. rebase is entirely up to the user,
and we are not changing that.

The purpose of this change is to avoid doing a merge when the user
wanted a rebase, or maybe something more complicated. So a rebase
being complicated is not an issue, because we know that's what the
user wants, that's the whole reason we are trying to avoid the
automated merge.

>> Fortunately there probably are very few of these users.
>
> Maybe. I am not sure how one would measure.
>
> If you are interested, I can ask the opinion of some of the GitHub
> trainers. They see a lot of new users and have a sense of what kinds of
> confusion come up most frequently, what kinds of workflows they tend to
> see, etc. Their experience may be biased towards corporate-ish users,
> though, because those are the people who pay for training.

Ask. I'm sure they will tell you doing merges by mistake with 'git
pull' is an issue.

>> > The current warning message in jc/pull-training-wheel is quite neutral
>> > between the two options. Perhaps we should lean more towards merging?
>>
>> I don't like that message. I would like this for the deprecation period:
>>
>> "The pull was not fast-forward, in the future you would have to choose
>> a merge or a rebase, merging automatically for now. Read 'man git
>> pull' for more help."
>>
>> Then when obsolete:
>>
>> The pull was not fast-forward, please either merge or rebase.
>
> A deprecation message helps people who are making the transition from an
> older behavior to a newer one. It cannot help new users who start with a
> git version after the deprecation period.

The new users are told to either merge or rebase, if they don't know
what that means, they will go on look it up, just like they looked up
the 'git pull' command in the first place.

>> "Any more babysitting with essay long messages is counter-productive
>> to the vast majority of Git users."
>
> I think that is what we have advice.* for.

I don't understand what that means.

-- 
Felipe Contreras