Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
If rebased code is the same as merged code, yes, it was tested.
Posted Mar 20, 2012 12:56 UTC (Tue) by nevets (subscriber, #11875)
But that's the big "If". When I first started using git, the upstream maintainer use to rebase my changes into his tree. The problem I had was I never knew what changes he pulled. I would push out a patch series of commits but I never knew what patches actually made it upstream. This changed later when Linus told everyone how to do it, and my push requests were then merged.
The problem is that I can not check what patches I pushed actually made it into upstream. There were some cases that a patch or two was dropped, and I had no clue. It was dropped because of conflicts or someone questioned the patch. But because the other patches were rebased in, I had to go patch by patch to determine what was in and what was not, and this was very time consuming.
I totally understand the usefulness of git pull being a rebase, but it should not be the default. Could you imagine Linux if Linus rebased everyone's pull requests?
Posted Mar 20, 2012 21:38 UTC (Tue) by mathstuf (subscriber, #69389)
Posted Mar 20, 2012 22:30 UTC (Tue) by nevets (subscriber, #11875)
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?
Posted Mar 20, 2012 23:14 UTC (Tue) by mathstuf (subscriber, #69389)
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.
| (fast-forward merge on top of B, then rebase L on top of R)
pull --rebase (no -p flag):
pull --rebase (with -p flag):
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.
Posted Mar 21, 2012 15:42 UTC (Wed) by misiu_mp (guest, #41936)
A - B - C - D - H
F - G
A - B - C - D - F - G
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds