On Sun, Feb 24, 2008 at 07:46:59PM +0000, Henrique de Moraes Holschuh wrote: > 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...
For having worked quite a bit in git.git (I sent my 100th patch that should go upstream on yesterday), I can tell that it's not true. I mean, the very people designing git, are also the one using it in the kernel developpement, and look at git history, it's a suite of topic branches merges. For example, look at all the commits named 'merged branch ph/...' that would be the branches that come from my work. And AFAICT, the kernel works in the very same way. What gets rebased though, are the bugfixes patches that come by 2 or 3, and that add no value when added as a specific branch. Usually those in git.git are applied on top of the 'maint' branch (aka the maintenance branch) and then merged back into master, and then back into 'next' (where the devel happens). IOW, it depends, and if you work on a new _feature_ it's really rarely rebased. > OTOH, if you don't care for clean history, then the point is moot and > rebasing is just a waste of everyone's effort. The question isn't about clean history, but a faithful one. When you rebase a branch, you pretend that you developped it on top of where you rebased it onto. Except that you didn't. > > 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. You're totally on crack, git bissect works really well across merges, and has really more chances to do so, because when you rebase, you usually e.g. don't check that intermediates points build, only the top. And an intermediate point that doesn't build is _WAY_ more likely to be a PITA for bisecting than a merge point. FWIW I bisect a lot, and bisect eliminates 'dead' branches (wrt the issue you want to track down) really efficiently. > 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. You vote for the mad route. Sorry, but it makes absolutely no sense to me. Ian's work was done at some point, tested from that point, and it makes sense to remember that fact. Actually it's insane to forget that fact. And rebasing is just pretending that fact never existed. It's just wrong. -- ·O· Pierre Habouzit ··O [EMAIL PROTECTED] OOO http://www.madism.org
pgpjVM63Zimu3.pgp
Description: PGP signature
