Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
It'd be great if the default for 'git pull' was to rebase
instead of merge ...
Posted Mar 19, 2012 16:43 UTC (Mon) by dskoll (subscriber, #1630)
I agree and I've configured my git to do that:
branch.autosetuprebase = always
Posted Mar 19, 2012 17:08 UTC (Mon) by slashdot (guest, #22014)
Rebase is the best option for work in progress or just unpublished commits, and that's what you almost always have if you are using "git pull" instead of "git merge" (well, not having any commit is even more likely, but there's no difference in that case).
Posted Mar 19, 2012 22:36 UTC (Mon) by Anssi (subscriber, #52242)
This seems such an obvious change to me, though, that there probably is some good reason why it hasn't been done already...
One potential issue that I can think of is that after such a change it would be easier to rewrite history. However, most histories are unpublished anyway, and git-push already rejects actually publishing a rewritten history, which should be enough I think.
Also, it would be a kind of big behavioural change... If that is an issue, maybe the "git pull" and "git pull --rebase" commands should be completely separated to different commands?
Posted Mar 20, 2012 0:46 UTC (Tue) by dlang (✭ supporter ✭, #313)
The 'right' way to do things is to have a branch that you use to track the upstream version, one or more branches that you do development in, and then you create test branches to test merging your work with the upstream work (rather than merging directly into your development or upstream branches). After you test the merge, you delete the branch, you defiantly don't do any more development on it.
only when you are ready to push do you do a merge that will be visible to the outside world and push out.
the excess merge commits that you are bothered by are an indication of real problems, but rebasing instead isn't any better.
Posted Mar 20, 2012 0:54 UTC (Tue) by dskoll (subscriber, #1630)
The 'right' way to do things depends on your development team's workflow and the project you're working on. For my main project with only a couple of developers, pull --rebase is almost always the 'right' thing to do.
Posted Mar 20, 2012 1:10 UTC (Tue) by dlang (✭ supporter ✭, #313)
> This seems such an obvious change to me, though, that there probably is some good reason why it hasn't been done already..
I was providing the reason why it's not such an obvious change.
Posted Mar 20, 2012 1:21 UTC (Tue) by Anssi (subscriber, #52242)
And after thinking about this a bit more, while I run "git pull --rebase" very often, most times it is on the upstream-tracking branch so "git pull" should actually work just the same.
That is, unless I've made some quick fix commit in the upstream-tracking branch before send-emailing it (when I've forgotten to create a branch for it), in which case "git pull" would do a merge while "git pull --rebase" would usually drop the local one. As said, though, that shouldn't happen :)
Posted Mar 20, 2012 10:57 UTC (Tue) by adobriyan (guest, #30858)
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
Posted Mar 20, 2012 17:12 UTC (Tue) by njs (guest, #40338)
I've seen people saying this for a while and it completely baffles me. Maybe you can explain.
What's so bad about merging from time-to-time as you work on your branch? That way you're sticking closer to upstream, can handle any changes and testing incrementally, and don't have to repeat merges over and over. I know it can work -- we did this all the time in monotone (the predecessor to git and hg), and it was wonderful. You end up with extra merges recorded in history, but who cares... they happened... they let future merges work better... instead we have kluges like git-rerere that try to tack a fake merge tool onto a system that already has a real one.
Back in the CVS days the inability to track merges into branches was considered one of the biggest bugs. Now that we fixed it, everyone seems to think that was actually a feature. Why?
Posted Mar 20, 2012 18:39 UTC (Tue) by dlang (✭ supporter ✭, #313)
I agree it sounds like it should improve development, but as I understand it, the actual result is that it complicates matters because you are pulling in unrelated changes with each merge. These unrelated changes may cause other problems along the way.
I suspect that how big an issue this is depends on the scope of the changes you are making.
If you are working on global-scale changes that touch lots of places, keeping up with upstream changes is more important, and just about all changes are relevant to the work that you are doing.
If you are working on a subsystem that is (relatively speaking) a small portion of the whole, then there are fewer benefits and more drawbacks.
Posted Mar 21, 2012 16:03 UTC (Wed) by misiu_mp (guest, #41936)
Posted Mar 21, 2012 14:12 UTC (Wed) by slashdot (guest, #22014)
If you aren't actively developing it, then you should have it published already, and thus merge is correct.
pull and push
Posted Mar 20, 2012 14:44 UTC (Tue) by jengelh (subscriber, #33263)
(Echo coming back to you:) It'd be great if pull actually did fetch rather than merge. (For going in line with being the antonym of push.)
Posted Mar 21, 2012 23:05 UTC (Wed) by man_ls (guest, #15091)
Is it completely safe to use though? I am afraid that my commits will grow long hair and learn to play banjo after a pull --rebase.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds