On Sun, Sep 08, 2013 at 11:03:52AM +0100, John Keeping wrote:
> > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html