Jarg Sommer writes ("Re: triggers in dpkg, and dpkg maintenance"):
> Ian Jackson <[EMAIL PROTECTED]> wrote:
> > 24 Oct 2007 - Raphael Hertzog asks me to `git-rebase', edit the email
> > address in my git commit logs, and so forth, allegedly
> > in order to make my changes easier to review. At the
> > time I was reliably informed by git experts that
> > published branches should not be rebased. As a rather
> > more experienced git user it seems clear to me now that
> > I was right to resist.
>
> There's no problem starting a new branch and rebasing this.
>
> % git branch trigger-new trigger
> % git rebase master trigger-new
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.
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.
The triggers branch has both properties: my experimental flex parser
branch is based off the triggers branch, as well as various smaller
bugfix branches, and obviously the branch has been published by my
various mailing list announcements and bug reports.
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.
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!
The reason it doesn't work well is that rebase, like patch/diff,
discards the revision history. git no longer knows when trying to do
the second merge that the triggers commits on the main branch are the
same as the ones on the flex branch. So it tries to apply them again,
which doesn't work. git's algorithm is clever enough, like cvs's but
unlike some version control systems', to spot the identical changes in
cases where there is no interaction between the flex and triggers
changes. But there are quite a few such interactions and every one
generate a spurious conflict.
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.
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.
Even if you thought a revision log containing an invented history was
a good idea, it's surely not worth manually resolving conflicts to get
it - especially in a project which has about three or four branches
and three or four committers.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
