Re: Pull is Mostly Evil

Jeff King wrote:

On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote:

quoted

Junio C Hamano wrote:

quoted

If we step back a bit, because we are forcing him to differentiate
these two pulls in his mental model anyway, perhaps it may help
people (both new and old) if we had a new command to make the
distinction stand out more.  What if the command sequence were like
this instead?

    $ git checkout maint
    $ git update [ origin maint ]

    $ git pull [--no-ff] developer-remote topic-branch
    $ git push [ origin maint ]

where the new command 'update' enforces the '--ff-only' update.  And
then we would stop telling "'git pull' first" when a push does not
fast-forward.

In addition to barf when it's not a fast-forward, such command can
switch the parents, so it appears 'maint' was merged to 'origin/maint'.
Many people have complained about this order.

I realize this has veered off into talking about an "update" command,
and not necessarily "pull", but since there a lot of proposals floating
around, I wanted to make one point: if we are going to do such a switch,
let's please make it something the user explicitly turns on.

This is sensible, but with warning "X will be the default in the
future", just like we did with push.default = simple.

One common workflow for GitHub users is to back-merge master into a
topic, because they want the final "integrated" version on the topic
branch. That lets it get review, run tests, and even get test-deployed
from there before merging to master (and then when it does merge to
master, we know the result will be a trivial merge).  This workflow
helps spread out the load (there is no central "integration" person or
script, and the merge itself becomes a possible part of the review/test
cycle).  Some projects will do this by rebasing the topic, but that has
its own complications (like making collaboration harder because the
commits are being frequently rewritten).

They can do:

% git pull origin master

That shouldn't revese the bases.

Such users are going to run "git pull origin master" or just "git pull"
to get that merge.

I'd say the vast majority of users running "git pull" want the parents
reversed, the minority that doesn't can switch to "git pull origin
master" (or add a configuration).

A switch to disallowing non-ff is going to disrupt
that workflow.

Only if the refuse to do "git pull origin master".

But I think that is the same moment they should probably be deciding on
whether their workflow wants "regular" or "reverse" merges. And I do not
think the decision between the two has an obvious split over which is
better.

Because there hasn't been enough discussion on this topic. I'm fairly
certain there will be consensus once concrete proposals are properly
discussed.

Most likely the consensus and the proposals will be ignored and nothing
will change as usual, but that's a different thing.

-- 
Felipe Contreras