Re: Pull is Mostly Evil

From: Jeff King <peff@peff.net>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Marc Branchaud <marcnarc@xiplink.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Pull is Mostly Evil
Date: Fri, 2 May 2014 17:48:17 -0400	[thread overview]
Message-ID: <20140502214817.GA10801@sigill.intra.peff.net> (raw)
In-Reply-To: <5363edc954f8e_70ef0f30c24@nysa.notmuch>

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.

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

Such users are going to run "git pull origin master" or just "git pull"
to get that merge. A switch to disallowing non-ff is going to disrupt
that workflow.  I think we can live with that, as they should be able to
stop and say "no, my workflow wants these merges", set a config
variable, and be done.

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. So it makes sense to me to take the opportunity when the user is
thinking about their workflow to have them specify one or the other.

-Peff