Re: Pull is Mostly Evil

[Richard Hansen <rhansen@bbn.com>]

On 2014-05-04 06:17, Felipe Contreras wrote:
> Richard Hansen wrote:
>> On 2014-05-03 23:08, Felipe Contreras wrote:
>>> It is the only solution that has been proposed.
>>
>> It's not the only proposal -- I proposed a few alternatives in my
>> earlier email (though not in the form of code), and others have too.  In
>> particular:
>>
>>   * create a new 'git integrate' command/alias that behaves like 'git
>>     pull --no-ff'
> 
> Yeah but that's for a different issue altogheter. I doesn't solve the
> problems in 1. nor 2. nor 3.

'git integrate' would handle usage cases #2 (update a published branch
to its "parent" branch) and #3 (integrate a completed task into the main
line of development), making it feasible to change 'git pull' and 'git
pull $remote [$refspec]' to default to --ff-only to handle usage case #1
(update local branch to @{u}).

> 
>>   * change 'git pull' and 'git pull $remote [$refspec]' to do --ff-only
>>     by default
>>
>> Another option that I just thought of:  Instead of your proposed
>> pull.mode and branch.<name>.pullmode, add the following two sets of configs:
>>
>>   * pull.updateMode, branch.<name>.pullUpdateMode:
>>
>>     The default mode to use when running 'git pull' without naming a
>>     remote repository or when the named remote branch is @{u}.  Valid
>>     options: ff-only (default), merge-ff, merge-ff-there, merge-no-ff,
>>     merge-no-ff-there, rebase, rebase-here, rebase-here-then-merge-no-ff
> 
> Those are way too many options to be able to sensibly explain them.

Certainly this is too many options for a first patch series, but I don't
think they're unexplainable.  (I listed a bunch of options because I was
trying to envision where this might take us in the long run.)

For the first patch series, I'd expect:  merge (which uses the merge.ff
option to determine whether to ff, ff-only, or no-ff), rebase, and ff-only.

Later ff-only would be made the default.

Later some or all of the other options would be added depending on user
interest.

> 
>>   * pull.integrateMode, branch.<name>.pullIntegrateMode:
>>
>>     The default mode to use when running 'git pull $remote [$refspec]'
>>     when '$remote [$refspec]' is not @{u}.  Valid options are the same
>>     as those for pull.updateMode.  Default is merge-ff.
>>
>> This gives the default split behavior as you propose, but the user can
>> reconfigure to suit personal preference (and we can easily change the
>> default for one or the other if there's too much outcry).
> 
> If we reduce the number of options to begin with (more can be added
> later),

yup

> then it might make sense to have these two options.
> 
> However, that doesn't change the proposal you described above (1. 2.
> 3.).

Not sure what you mean.  I oulined three usage cases:
  #1 update local branch to @{u}
  #2 update a published branch to its "parent" branch
  #3 integrate a completed task into the main line of development

Having these two sets of options (updateMode and integrateMode) would
make it possible to configure plain 'git pull' to handle usage case #1
and 'git pull $remote [$refspec]' to handle usage cases #2 and #3.

Or the user could configure 'git pull' and 'git pull $remote [$refspec]'
to behave the same, in case they find the different behaviors to be too
confusing.

> There's something we can do, and let me clarify my proposal. What you
> described above is what I think should happen eventually, however, we
> can start by doing something like what my patch series is doing; issue a
> warning that the merge is not fast-forward and things might change in
> the future.

OK, let me rephrase to make sure I understand:

  1. leave the default behavior as-is for now (merge with local
     branch the first parent)
  2. add --merge argument
  3. add ff-only setting
  4. plan to eventually change the plain 'git pull' default to ff-only,
     but don't change the default yet
  5. add a warning if the plain 'git pull' is a non-ff
  6. wait and see how users react.  If they're OK with it, switch the
     default of the plain 'git pull' to ff-only.

Is that accurate?  If so, sounds OK to me.

> 
> If people find this behavior confusing they will complain in the mailing
> list.

true

> Although I suspect it would be for other reasons, not the 'git
> pull'/'git pull $there' division.

probably

> Either way we would see in the discussion.

sounds good to me

> 
>>>>>>  3. integrate a more-or-less complete feature/fix back into the line
>>>>>>     of development it forked off of
>>>>>>
>>>>>>     In this case the local branch is a primary line of development and
>>>>>>     the remote branch contains the derivative work.  Think Linus
>>>>>>     pulling in contributions.  Different situations will call for
>>>>>>     different ways to handle this case, but most will probably want
>>>>>>     some or all of:
>>>>>>
>>>>>>      * rebase the remote commits onto local HEAD
>>>>>
>>>>> No. Most people will merge the remote branch as it is. There's no reason
>>>>> to rebase, specially if you are creating a merge commit.
>>>>
>>>> I disagree.  I prefer to rebase a topic branch before merging (no-ff) to
>>>> the main line of development for a couple of reasons:
>>>
>>> Well that is *your* preference. Most people would prefer to preserve the
>>> history.
>>
>> Probably.  My point is that the behavior should be configurable, and I'd
>> like that particular behavior to be one of the options (but not the
>> default -- that wouldn't be appropriate).
> 
> All right. But I'm a bit overwhelmed by all the things to keep in mind.

Sure, this would be an option to add later.

> Does your proposed IntegradeMode/UpdateMode deal with this?

mode = rebase-here-then-merge-no-ff would do what I described

> Anyway, I'll try to grab what I can from previous discussions (mainly
> about switching the merge parents) and create a new thread with a
> summary.

That would be nice, thanks.

-Richard