[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)



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                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgpd73i8cDgDi.pgp
Description: PGP signature


Reply to: