Re: Pull is Mostly Evil

Richard Hansen wrote:

On 2014-05-04 06:17, Felipe Contreras wrote:

quoted

Richard Hansen wrote:

quoted

On 2014-05-03 23:08, Felipe Contreras wrote:

quoted

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

But these cases are completely different. One should reverse the
parents, the other one not.

I feel if a new command is to be added, it should be the one that is
introducing the brand new behavior: switching the parents. So it would
be appropriate for 1. and 2.

quoted

quoted

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

Actually I think they are too many for any point in time.

Maybe pull.updateArgs would make more sense.

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.

Seems sensible.

quoted

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.

Not if by default they are already handled.

quoted

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.

That is what my patch series is doing already, basically.

The new warning I'm proposing would be for the split behavior of 'git
merge' and 'git merge $there'. Which is what is worrysome.

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

I think that mode is way too specific to be useful for most people.

-- 
Felipe Contreras