Re: Pull is Mostly Evil

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

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

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

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