| |||||||||||||
pull --rebasepull --rebasePosted Mar 20, 2012 23:14 UTC (Tue) by mathstuf (subscriber, #69389)In reply to: pull --rebase by nevets Parent article: Git project seeks discussion on "push" change
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.
(Log in to post comments)
|
|||||||||||||