Re: [PATCH 0/3] Reject non-ff pulls by default

From: Greg Troxel <gdt@ir.bbn.com>
Date: Sep 5, 2013, 13:31 UTC
Message-ID: <rmi8uzbz96g.fsf@fnord.ir.bbn.com>
In-Reply-To: <xmqqa9jso69u.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 7 quoted lines

> Peff already covered (1)---it is highly doubtful that a merge is
> "almost always wrong".  In fact, if that _were_ the case, we should
> simply be defaulting to rebase, not failing the command and asking
> between merge and rebase like jc/pull-training-wheel topic did.
>
> We simply do not know what the user wants, as it heavily depends on
> the project, so we ask the user to choose one (and stick to it).

From my experience leading the first large project using git at BBN, evolving a workflow (most work on topic branches, which are rebased, banning 'git pull'-created merge commits, and explicit merge commits to preserve --first-parent, basically), and seeing many people struggle to learn all this, my take is that a user who does not understand non-ff merge vs ff-merge vs rebase will end up doing the wrong thing. So two thoughts:

  In the glorious future, perhaps git could have a way to express a
  machine-parseable representation of the workflow and rules for a repo,
  so that these choices could be made accordingly.

  In the current world, I think it makes sense to error out when there
  are multiple reasonable choices depending on workflow.

One of my team members, Richard Hansen, has argued to us that 'git pull' is harmful, essentially because it creates non-ff merges sometimes, while our rules say those should be rebased out. So we use

[alias]
	up = !git remote update -p && git merge --ff-only @{u}

which acts like pull if ff merge works, and otherwise errors out.

I think the key question is: can a user who doesn't really understand the implications of ff vs non-ff merges and the local workflow rules actually function ok, or do they need to stop and go back and understand. I'm in the "you just have to take the time to understand" camp, which led to us having a semi-custom syllabus from github training covering rebase, explicit vs ff merges and the consequences for first-parent history, etc.

Therefore, I think "git pull" should do the update (perhaps of just the remote corresponding to @{u}, perhaps without -p) and a --ff-only merge, absent a configuration asking for non-ff merge or rebase. (Arguably, an ff merge is a degenerate case of rebase and also of the ff/non-ff merge, so it's safe with either policy.)

Greg