Re: Pull is Mostly Evil

> On 2014-05-03 23:08, Felipe Contreras wrote:
> > Richard Hansen wrote:
> >> Or are you proposing that pull --merge should reverse the parents if and
> >> only if the remote ref is @{u}?
> > 
> > Only if no remote or branch are specified `git pull --merge`.
> 
> OK.  Let me summarize to make sure I understand your full proposal:
> 
>   1. if plain 'git pull', default to --ff-only
>   2. if 'git pull --merge', default to --ff.  If the local branch can't
>      be fast-forwarded to the upstream branch, then create a merge
>      commit where the local branch is the *second* parent, not the first
>   3. if 'git pull $remote [$refspec]', default to --merge --ff.  If the
>      local branch can't be fast-forwarded to the remote branch, then
>      create a merge commit where the remote branch is the second parent
>      (the current behavior)
> 
> Is that accurate?

> >> If we change 'git pull' to default to --ff-only but let 'git pull
> >> $remote [$refspec]' continue to default to --ff then we have two
> >> different behaviors depending on how 'git pull' is invoked.  I'm worried
> >> that this would trip up users.  I'm not convinced that having two
> >> different behaviors would be bad, but I'm not convinced that it would be
> >> good either.
> > 
> > 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'

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

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

> > Moreover, while it's a bit worrisome, it wouldn't create any actual
> > problems. Since `git pull $what` remains the same, there's no problems
> > there. The only change would be on `git pull`.
> > 
> > Since most users are not going to do `git pull $what` therefore it would
> > only be a small subset of users that would notice the discrepancy
> > between running with $what, or not. And the only discrepancy they could
> > notice is that when they run `git pull $what` they expect it to be
> > --ff-only, or when the run `git pull` they don't. Only the former could
> > be an issue, but even then, it's highly unlikely that `git pull $what`
> > would ever be a fast-forward.
> > 
> > So althought conceptually it doesn't look clean, in reality there
> > wouldn't be any problems.
> 
> Yes, it might not be a problem, but I'm still nervous.  I'd need more
> input (e.g., user survey, broad mailing list consensus, long beta test
> period, decree by a benevolent dictator) before I'd be comfortable with it.

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

> >>   * It makes commits easier to review.
> > 
> > The review in the vast majority of cases happens *before* the
> > integration.
> 
> True, although even when review happens before integration there is
> value in making code archeology easier.

> > And the problem comes when the integrator makes a mistake, which they
> > inevitable do (we all do), then there's no history about how the
> > conflict was resolved, and what whas the original patch.
> 
> Good point, although if I was the integrator and there was a
> particularly hairy conflict I'd still rebase but ask the original
> contributor to review the results before merging (or ask the contributor
> to rebase).