GRUB packaging -> git

[Colin Watson]

On Thu, Nov 21, 2013 at 12:27:05PM +0000, Colin Watson wrote:
> 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.

I've now had the chance to try out git-dpm on a number of smaller
packages.  I am completely sold on it and am converting everything with
patches that I maintain to it, as time permits.  It works by
automatically round-tripping between debian/patches/ and a synthetic
"patched" branch, which is upstream with each of debian/patches/ applied
as a separate commit.  The patched branch is rebasing using the normal
tools, so if you wanted to change a patch in the middle of the stack you
could use:

  git-dpm checkout-patched
  git rebase -i upstream
  # change "pick" to "edit" for the patch in question
  # hack hack hack
  git commit --amend
  git rebase --continue
  git-dpm dch -- "message"
  # or "git-dpm update-patches" for more control

Adding a new patch would just be:

  git-dpm checkout-patch
  # hack hack hack
  git commit -a
  git-dpm dch -- "message"

Either way, this will end up merging the tip of the rebased "patched"
branch into your main working branch, updating all the patch files
automatically.

You never touch quilt again, although somebody who's unpacked the source
package with "dpkg-source -x" is still able to do so quite happily, and
the source package is just as readable as before.  Patch headers are
round-tripped with commit messages on the "patched" branch, so you can
still have DEP-3 metadata, and you can cherry-pick directly from
upstream onto the "patched" branch.  I think this is pretty close to the
best of both worlds.

There are a few downsides, most of which are mitigated in some way:

 * "git blame" doesn't *quite* work properly in some cases after you've
   edited a patch, although no information is lost and it can be made to
   work with a small patch to git
   (http://comments.gmane.org/gmane.comp.version-control.git/239861).

 * "git log" ends up being rather noisy when making changes deep in
   large patch stacks.  "git log --first-parent" helps, or you can use
   gitk or similar; "git show -m" helps when looking at one of the merge
   commits.

 * This is an enforced workflow change; you can't mix and match this
   with manual developer use of quilt in a particularly sane way, and
   you have to use git-dpm if you're touching patches in any way.  (I
   guess it's recoverable if somebody makes a mistake, but I'd rather
   not have to do that too often.)

 * git-dpm is a bit picky about making sure that enough of the state of
   the upstream tree is represented in git.  On the other hand, it
   provides tools such as "git-dpm import-tar" to help with that.

 * "git-dpm init" doesn't round-trip existing debian/patches/ files
   exactly.  There's no data loss, but it reformats the patch headers in
   a "git format-patch" style, and it may reorder patches and change
   their style a bit.  On the other hand, it enforces a consistent
   format, so patch formats don't oscillate as different developers with
   different .quiltrc files run "quilt refresh".

 * As well as needing to use "git-dpm init --record-patch-name" to
   remember patch names from before git-dpm was in use, you need to
   manually add "Patch-Name: foo.patch" to commit messages (or use
   "git-dpm apply-patch --name" etc.) to get git-dpm to export better
   file names than the defaults generated by "git format-patch".

I think this kind of thing is absolutely worth it to avoid having to
tell people how to initialise their quilt metadata after checking out a
branch, and to avoid the upstream merge madness that I described in my
last post.  While the git representation of patch stacks is a bit noisy,
as I mentioned, it also seems very idiomatic for git, and it has several
useful properties.

Does anyone have any objections to me setting this up?  If I don't hear
anything, I'll probably go ahead in a week or so.

Cheers,

-- 
Colin Watson                                       [cjwatson at debian.org]