GRUB packaging -> git

[Colin Watson]

Since GRUB upstream has moved from bzr to git, the path of least
resistance was to convert the Debian packaging as well.  I've done so,
and you can see the result here:

  http://anonscm.debian.org/gitweb/?p=pkg-grub/grub.git

I didn't make any changes to the layout of the source package in the
process, so it's still a 3.0 (quilt) package in the patches-applied
state.  For as long as I'm doing the bulk of the maintenance work I
insist on patches-applied, even though it makes some things more
complicated; I really need to be able to use "git blame" and "git log"
on a file and see its history including both upstream changes and
changes applied in Debian patches.  It makes all kinds of analysis work
immeasurably easier.

However, there are a couple of downsides.  The first is that when
pulling changes from other people you often need to reset the state of
your local quilt stack (because I find checking in .pc even more
confusing than not doing so): the easiest way to do this is to make sure
you have no local changes, "rm -rf .pc", and then run
http://people.canonical.com/~cjwatson/dpkg-quilt-setup.

The second and more serious downside is that it makes merging from
upstream more complex, and this is worse with git than with bzr due to a
problem I didn't foresee.  With bzr, the procedure was as follows
(pseudocode):

  quilt pop -a
  bzr merge --force  # should apply without conflicts
  while quilt push; do
    resolve conflicts as necessary
    quilt refresh
  done
  bzr commit

This was a little bit fiddly, but not too bad.  However, "git merge"
refuses to operate if you have uncommitted changes in your working tree
and cannot be forced; just about everyone's first response to this is
"do you know about git stash?", to which the answer is yes I do but it's
precisely not what's needed because the entire point is to pop the quilt
stack first so that conflicts there can be resolved in quilt later,
allowing us to produce a clean quilt stack at the other end.  This means
the "quilt pop -a" step has to be committed first, but it must not end
up in the history after the merge because that will make "git blame"
useless.  To make matters worse, "git rebase" is not able to squash onto
a merge.

The simplest procedure I've been able to come up with, thanks to Ian
Jackson, is as follows, assuming that the merge is intended to end up on
the "experimental" branch; the cat-file | hash-object dance constructs a
new commit object with the fully-merged tree state but with adjusted
parent pointers to snip the "quilt pop -a" commit out of the history:

  git checkout -b tmp-merge
  quilt pop -a
  git commit -m unquilt
  git merge --no-commit upstream
  while quilt push; do
    resolve conflicts as necessary
    quilt refresh
  done
  git add <anything untracked except for debian/grub-extras/ and
           debian/legacy/update-grub>
  git commit
  git checkout experimental
  real_parent="$(git rev-parse experimental)"
  commit="$(git cat-file commit tmp-merge | \
    perl -pe 'unless ($done) { s/^parent .*/parent '"$real_parent"'/ and $done = 1; }' | \
    git hash-object -t commit -w --stdin)"
  git branch -f tmp-merge "$commit"
  sanity-check tmp-merge using gitk and/or "git log"
  git merge --ff-only tmp-merge

This is just about bearable aith a little scripting; I've done it a few
times now on the experimental branch and it seems to have worked out OK.
But it's clearly rather more fragile than is ideal.

The right answer is probably to have the patch stack represented as a
stack of git topic branches and automatically export the quilt stack
from that.  There are various tools that purport to do this.  git-dpm
seems to have design goals that match mine, and I'm inclined to try it
out first, except that I haven't yet managed to wrap my head around its
documentation which is composed mainly of commit graphs.  I think I
shall try it out on a simpler package before attempting to apply it to
grub2.

For now, this should be by and large good enough, and at least makes it
feasible to merge again.  I hope to get a new upstream snapshot uploaded
to experimental some time next week, at which point we can start seeing
whether it resolves any of the remaining RC bugs that are keeping GRUB
2.00 out of testing.

Cheers,

-- 
Colin Watson                                       [cjwatson at debian.org]