4 ms·

While this makes sense when dealing with a central repo (which I agree is the vast majority of use cases), it's inaccurate. You're rewriting history so that it

by wonnage 14y ago

While this makes sense when dealing with a central repo (which I agree is the vast majority of use cases), it's inaccurate. You're rewriting history so that it looks like your work happened on top of $REMOTE's work, when in reality it was the other way around. This becomes a problem if you're working with multiple remotes, and which remote you pulled from, and when you did it becomes an actual concern. Concrete example: if I'm the maintainer of wonnage/foo and bar submits a pull request from bar/foo, using git pull bar --rebase doesn't make a whole lot of sense.

kelnos 14y ago
Of course, that's absolutely correct. But that's the minority use case, at least in my experience. Git's default is set up that way because of how the Linux kernel maintainers work, which isn't how most organizations who use git work. Even though git is distributed, most orgs have a central repo that they use as the source of truth. When contributors pull from this central repo, IMO they should be rebasing, not merging. When the maintainer pulls from other people, yes, he should of course be merging. The merge commit that a contributor implicitly creates when they resync with upstream (without rebasing) is ugly and confusing. It provides no useful information and only serves to clutter the project's history, not make it clearer.
- jedbrown 14y ago
  A topic branch workflow is tremendously useful even without separate people in the "developer" and "integrator" roles. For example, we have about 20 people regularly developing code and about five of us "integrate", first to 'next', then to 'master' when a feature has stabilized. We don't explicitly pass an integrator token so there is a possible race to the integration branch, but since we only merge there, it's actually pretty rare in practice. If you lose the race, the polite thing to do is discard your old merge, fast-forward, and repeat the merge. This preserves first-parent. http://git-blame.blogspot.com/2012/03/fun-with-first-parent.html http://git-blame.blogspot.com/2012/03/fun-with-first-parent....
erso 14y ago
Your example is incorrect. If you're the maintainer of wonnage/foo and bar submits a pull request from bar/foo, bar/foo should have been rebased on top of wonnage/foo, not the other way around. (And if you are in a situation where rebasing on top of bar/foo would actually do anything, that means you have local commits that haven't been pushed to origin, in which case accepting the pull request is dangerous.)

by wonnage 14y ago

kelnos 14y ago

Of course, that's absolutely correct. But that's the minority use case, at least in my experience. Git's default is set up that way because of how the Linux kernel maintainers work, which isn't how most organizations who use git work. Even though git is distributed, most orgs have a central repo that they use as the source of truth. When contributors pull from this central repo, IMO they should be rebasing, not merging. When the maintainer pulls from other people, yes, he should of course be merging. The merge commit that a contributor implicitly creates when they resync with upstream (without rebasing) is ugly and confusing. It provides no useful information and only serves to clutter the project's history, not make it clearer.

jedbrown 14y ago
A topic branch workflow is tremendously useful even without separate people in the "developer" and "integrator" roles. For example, we have about 20 people regularly developing code and about five of us "integrate", first to 'next', then to 'master' when a feature has stabilized. We don't explicitly pass an integrator token so there is a possible race to the integration branch, but since we only merge there, it's actually pretty rare in practice. If you lose the race, the polite thing to do is discard your old merge, fast-forward, and repeat the merge. This preserves first-parent. http://git-blame.blogspot.com/2012/03/fun-with-first-parent.html http://git-blame.blogspot.com/2012/03/fun-with-first-parent....

erso 14y ago

Your example is incorrect. If you're the maintainer of wonnage/foo and bar submits a pull request from bar/foo, bar/foo should have been rebased on top of wonnage/foo, not the other way around. (And if you are in a situation where rebasing on top of bar/foo would actually do anything, that means you have local commits that haven't been pushed to origin, in which case accepting the pull request is dangerous.)