pull --rebase [LWN.net]

pull --rebase

Posted Mar 20, 2012 21:38 UTC (Tue) by mathstuf (subscriber, #69389)
In reply to: pull --rebase by nevets
Parent article: Git project seeks discussion on "push" change

Unless I'm sorely mistaken, pull --rebase doesn't rebase pulled branches onto another branch. Instead, it rebases any changes that you have locally that are on a branch onto whatever you pulled down from the remote for that branch. The only problem I've encountered with this when I've made merges into master or next and pulling rebases the merge on top of the tree. A pull --rebase should probably pass -p to rebase so that merges are re-merged instead of streamlined on the branch.

(Log in to post comments)

pull --rebase

Posted Mar 20, 2012 22:30 UTC (Tue) by nevets (subscriber, #11875) [Link]

You may not be mistaken, I may be. I've never used a pull --rebase before, as that's not part of my workflow.

My workflow would be to do a git remote update of the repo that I'm going to base my work on, and then start adding commits to it. Then push those changes upstream.

The repos I take changes from, I do a pull from others, which I do not want to have any rebase (mine or theirs). If you pull from multiple people, how would this work? One pull would rebase against the other.

If I have old commits and want to rebase them on the latest upstream, I simply do a git remote update of the upstream branch and then do a local rebase.

Now I'm confused to the purpose of pull --rebase?

pull --rebase

Posted Mar 20, 2012 23:14 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Suppose you have two machines with different commits on some branch. You push from one machine to a common remote repository. On the other machine, you need to pull.

Before:

--B--R (origin/branch)


--B--L (branch)

pull --merge:

--B--R
      \
       \
--B--L--R'

pull --rebase:

--B--R
     | (fast-forward merge on top of B, then rebase L on top of R)
     |
--B--R--L'

The problem is that pull --merge creates a merge commit on the branch with "itself". These commits are, IMNSHO, ugly and shouldn't happen. Now what happens if L is some topic branch that got merged into the branch?

Before:

--B--R (origin/branch)


--B-----L (branch)
       /
      /
--S--T (topic)

pull --rebase (no -p flag):

--B--R
     |
     |
--B--R--S'--T'

pull --rebase (with -p flag):

--B--R
     |
     |
--B--R--L'
       /
      /
--S--T

With the -p flag, pulling from the remote, keeps the repository looking most similar to what it did before the pull which is one reason why I like it more. The other is that I believe that feature branch merges should *always* use --no-ff so that reverting them is easy (reverting L' is easy; S' and T' less so, especially if topic will land later at some point and it's just broken now).

As for multiple remotes sharing a single branch name, all I can say is that I prefer to not do that. I name remotes in namespaces for non-origin repositories (so foobar's github clone is the gh/foobar remote and I checkout foobar's branches as foobar/branchname). Even my forks get named gh/mathstuf on my machines so that if I keep a personal master branch (mathstuf/master) with my feature branches merged in, it doesn't conflict with the actual master branch. My personal feature branches get named under the dev/ namespace and are not under a username. If they become collaborative, then I'd start namespacing them.