Re: [PATCH 0/3] Reject non-ff pulls by default
- From
Jeff King <peff@peff.net>
- Date
- Sep 9, 2013, 20:04 UTC
- Message-ID
- <20130909200438.GD14021@sigill.intra.peff.net>
- In-Reply-To
- <20130908100351.GI2582@serenity.lan>
On Sun, Sep 08, 2013 at 11:03:52AM +0100, John Keeping wrote:
Show 18 quoted lines
> > 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