Re: Pull is Mostly Evil

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 2, 2014, 21:55 UTC
Message-ID: <536414352fa24_1976139f2f0f9@nysa.notmuch>
In-Reply-To: <20140502214817.GA10801@sigill.intra.peff.net>

Jeff King wrote:

Show 27 quoted lines

> On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote:
> 
> > Junio C Hamano wrote:
> > > 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.

Show 10 quoted lines

> 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