pull --rebase [LWN.net]

pull --rebase

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

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?

(Log in to post comments)

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.