On Sun, 24 Feb 2008, Ian Jackson wrote: > But for the reasons which were discussed at length on debian-dpkg in > October, this is not a good idea. Sadly I was not able to persuade > Raphael.
Given that many of us work on the kernel, some of us are both upstream and downstream in git, and therefore know *both* sides of the troubles and advantages of git rebase quite well... I can see why you'd have a tough time convincing anyone to change his mind about it. We will have lived it ourselves and made up our minds about it a long time ago, already... > One should not rebase a git branch which has had other branches taken > from it, nor should one rebase a git branch which has ever been > published (at least, unless it has been published with a warning > announcing that it might be rebased). Both of these practices lead to > severe problems. Correct. Yet, rebasing is still routinely performed in the Linux kernel development. Indeed it should not be done for trivial reasons, as it does cause more work downstream, so the question is: what is a non-trivial reason? In the Linux kernel, we (as downstream) will usually cope with the problems it causes if it means clean history upstream. IMO, such behaviour is much better for the whole project later on. Say, in five years or so, when a different team will be working on dpkg. Or when someone is trying to chase down a bug, and has to look into the history to understand something. Many of the important subsystems in the Linux kernel community lives with this, it would not be done like that if rebasing was just a cosmetic thing. For one, merging properly rebased branches makes it a *LOT* easier to bissect, otherwise, you could find yourself bissecting a dpkg of two years ago to test a recently-merged feature whose work branches were started that long ago... In fact, it is bad enough in the kernel already, even with so much rebasing going on, because often the kernel you get while bissecting is just pure crap because people don't test enough before they send merge requests :-) > If the main git branch pulls a rebased version of my triggers branch > rather than the original, or if the same thing is attempted with patch > and diff, then attempts to merge the main head back into the flex > parser branch fail with conflicts. Raphael assured me that it would > work just fine so I actually tried it, and so did Raphael later. The > results were a pile of conflicts to fix up, as I had predicted. Yes. One has to just tough it up and rebase everything (and so does one's downstream). Rebase often enough in key points, and it won't be such a big pain to keep up with it. > See the results of the workflow that Raphael is suggesting: > http://lists.debian.org/debian-dpkg/2007/10/msg00206.html > > You probably want to skip the discussion and look at the transcript, > about two thirds of the way down. Note that this is Raphael's message > and the transcript he is presenting is what he apparently considers > acceptable behaviour! Sure he does. We have a few thousand doing it in the kernel, why shouldn't he consider it acceptable? It is not done just for the kick of it. Clean history has a real benefit when it comes down to debugging and new developers joining in. Heck, some subsystems (like ACPI) have a rule where you have to *separate* all your changes into *rebased and clean* topic branches, merge them over a clean rebased branch from upstream, and submit the result of THAT merge. If you don't do it, the upstream maintainer will do it for you by force (and pick up your patches by email only, never pulling from you). OTOH, if you don't care for clean history, then the point is moot and rebasing is just a waste of everyone's effort. > This can be avoided by using git properly. It already knows how to > track which changes have already been merged. If you do it the right > way (ie, just merge from my branch) then there are no conflicts. > Everything is automatic; it just does the right thing. That would require your branch to be very clean, and would still cause issues when bissecting. If you never do bissects, and you don't care for a mess here and there in the history, indeed there is no good reason for rebasing. > Of course you get a slightly messier revision history because the main > dpkg revision history will then contains everything I actually did, > rather than some sanitised rewrite of history. I think this is good > because I want to know the actual context of a change, but Raphael > thinks it is a problem because he wants a clean and pretty revision > log. Yep. The real question is: which one is useful to people doing debugging and new developers joining in? Is that worth the effort? I vote for clean history and a bissectable tree, and I think it is worth the effort. But I am no dpkg developer, this is a thing you guys have to find an agreement among yourselves. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]