Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Mon, 25 Feb 2008, Pierre Habouzit wrote:
> 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.
Of course branches are merged. But some of them are *rebased* before the
merge request is sent. And rebased a lot while being developed, too (I
count stgit and such tools usage as rebasing).
> And AFAICT, the kernel works in the very same way. What gets rebased
No, it doesn't work always like that. Of course, parts of the kernel
development are really patch-based (stgit, quilt, quilt-on-top-of-git, etc),
and get into git at the last step only, and that may well have a lot to do
with it.
Heck, some subsystems and maintainers get patches only over email, which
is the same as a rebase from the patch submitter's PoV.
> > 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.
That's a way to look at it, yes.
> > 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.
Only if you are a lazy ass. Oh wait, that describes a LOT of developers out
there, in Debian and Linux alike ;-) *I* checkpatch (argh), build, AND do
a light runtime-test at every point of a set I am sending upstream (and
that's after the heavy testing during development). I can't speak for
others, though.
As for me being on crack, I better explain it a bit more what I mean,
apparently...
1. You start developing by branching from upstream (mainline)
2. Upstream fixes some critical bugs (maybe they are not critical for you,
but they are for a third party we will call "tester"), after you branched
from it. You either ignore any updates in mainline while working on your
branch, or (more likely, for long-lived branches) you merge from mainline
back into your branch a number of times during development (always
without rebasing).
3. You finish your work and ask upstream to pull from you.
How well will bissect work for the tester, now, if he is trying to find out
something that broke with the final merge between two points where something
*else* is broken in mainline?
I am not sure the above is something that happens on git or dpkg, but
happens all the time in the kernel. Merge of recently-rebased subsystem
trees lessen that pain a lot.
This is all due not to bugs in git, it is dealing just fine with the merges
and branches and bissecting those.
> FWIW I bisect a lot, and bisect eliminates 'dead' branches (wrt the
> issue you want to track down) really efficiently.
Yes, it does. But that is NOT enough for certain projects. And very
long-lived branches are the most likely ones to cause such problems.
> > 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.
There is no excuse for accepting untested code for merges in anything that
doesn't go at breakneck speed. So I have to either assume it is going to be
completely tested right before the merge, or right after it. Or both ;-)
If it is going to be tested by the submitter right before the merge, he
might as well do it properly and test it at every step of the changeset
(which is the right thing to do, if you want bissections to be easy) and at
that point, rebasing can't introduce new bugs. In fact, it will let the
submitter find any new latent bugs due to mainline changes *before*
submitting a merge request, which is the right thing to do.
If the maintainer has to test everything the submitter did after he merges
news code, he might as well clean up any dirty history, because that will
help testing and understanding the new code a lot. That means delays, and
one can't very well complain of the clean up the maintainer ends up doing
while at it.
And, as I covered before, the alternative of keeping your work tree mostly
up to date by merging with mainline often (no rebasing) can cause trouble
for testers trying bissections, and it *does* create a much more convoluted
history.
So, no, I am not on crack. I may be mistaken about something, but I am not
on crack.
--
"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: