Debian packaging with git and conflicts resolution

[martin f krafft]

also sprach Russ Allbery <rra at stanford.edu> [2008.11.19.0122 +0100]:
> You load the new upstream into the upstream branch.  Now, you merge the
> new upstream into the A, B, and C topic branches.  In each case, upstream
> used a slightly different bug fix than you had in their new release
> (different wording, different comments, different whitespace, what have
> you).  So in each of the topic branches, you had to resolve conflicts
> between the new upstream and your fix.

If upstream has fixed the problems that had you use A,B,C in the
first place, why merge them back into the integration branch? After
you merged upstream there, A,B,C have been obsoleted, no?

Anyway, I am starting to doubt the need for a long-lived integration
branch. What are the benefits of that approach, as opposed to
creating a new integration branch for each Debian release?

With TopGit, this would be as easy as merging upstream into master,
updating all branches (which has you resolving conflicts), and then
creating a new TopGit branch which depends on master (the
Debianisation branch) and all the topics you want in the next
release. The you build, test, upload, tag, and never touch the
branch again. There is not even a point in keeping the branch
around, since the tag keeps a reference to the tree you used.

I use this approach for topgit itself, except that my integration
branch isn't an integration branch, it's really a long-lived branch
off master (the Debianisation branch), into which you keep merging
master for each new release, recreate debian/patches with tg-export,
and commit the new patch series. In the end, this 'build' branch
just tracks the patch series on top of the master branch to use.

So in the end, the dependency graph is something like (branches are
capitalised, all except UPSTREAM and MASTER are TopGit-managed):

UPSTREAM ---+------------- FEATURES/*      (features against upstream)
 \          `- FIXES/*      |              (bug fixes against upstream)
  `- MASTER         \       |              (./debian/* files)
      | `- DEBIAN/*  \     /               (debian-specific changes)
      |         \     \   /
      |          `---- tg-export           (quilt series generation)
      |                   |
      `- BUILD         debian/patches/*    (BUILD tracks quilt series
                                            on top of latest master)

When you make a release, you build it from the BUILD branch and tag
right there.

When a new upstream comes around, TopGit is responsible for updating
FEATURES/* and FIXES/*, you merge UPSTREAM manually into MASTER[*]
and again rely on TopGit to update DEBIAN/*, you then merge MASTER
into BUILD and export the patch series, commit the changes, build,
tag...

[*] MASTER could be a TopGit branch too off UPSTREAM, and BUILD
could depend on MASTER, but then you would have to filter the
branches TopGit exports, or post-hoc remove the patches from the
quilt series, both of which complicate matters.

With this approach, no conflict ever has to be resolved twice,
though I bet it could happen if you have complex dependencies (e.g.
a DEBIAN/* branch depends on a FIXES/* branch).

Instead of exporting the quilt series, you could also create a new
integration branch with TopGit for each release, or collapse TopGit
branches into a single branch with one-commit-per-TopGit-patch.

The main problem that exists still is that it is currently not
possible to remove a TopGit branch when it is a dependency for
another branch. This is being worked on (there is a bug report for
it, "ability to remove a topgit branch", but since I am offline you
need to find it yourself).

The other problem, the main motivation for my current approach with
the quilt series, is that TopGit cannot be used to extract patches
for previous releases. Again, this is doable, but has to be
implemented. See the bug report "ability to create patches from
older states of topic branches" for this.

-- 
 .''`.   martin f. krafft <madduck at debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"writing a book is like washing an elephant: there no good place to
 begin or end, and it's hard to keep track of what you've already
 covered."
                                                        -- anonymous
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20081122/4d09c733/attachment.pgp