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

On Sun, Sep 08, 2013 at 11:03:52AM +0100, John Keeping wrote:

quoted

I know those are all balanced by some advantages of rebasing, but I also
think they are things that can be troublesome for a user who does not
fully grok the rebase process. I'm just wondering if we should mention
both, but steer people towards merging as the safer alternative (you
might have ugly history, but you are less likely to create a mess with
duplicate commits or badly-resolved conflicts).

The really correct thing to do here is to encourage a feature branch
workflow, but in my experience people are happier to walk through a
rebase than to switch over to feature branches completely.

An alternative pull mode would be:

    git reset --keep @{u} &&
    git merge @{-1}

which gets a sensible history shape without any of your disadvantages
above.  But that didn't go anywhere last time it came up [1] [2].

FWIW, that approach makes some sense to me. De-coupling for a moment the
idea of "what is the default" from "what are the options", it seems like
doing a reverse-merge would be a good option to have in the toolbox.

It would also have other uses beyond "git pull". For example, in
development of GitHub itself, we use topic branches. But before merging
them to master, we often test-deploy the topic to the live site. Before
doing so, you have to merge the topic with the latest master to make
sure you are not un-deploying anybody else's recently graduated topics.

You can do so by creating a temporary merge branch and deploying that,
or you can simply merge master back into the topic. We generally choose
the latter, because it leaves any conflict resolution in an obvious
place (and doesn't need repeating).

-Peff