Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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
Reply to: