Debian packaging with git and conflicts resolution

[martin f krafft]

also sprach Russ Allbery <rra at stanford.edu> [2008.11.22.1953 +0100]:
> It's also not an issue if you resolve conflicts between branches
> by making one branch depend on another, which in reading between
> the lines I think is the approach you're taking (although I could
> be wrong).

You got it, that's the beauty of TopGit. And I guess it's where
Manoj and I diverge. If we have two independent topic branches,
which modify two adjacent lines (and thus conflict with each other),
you have to resolve the conflict at some point:

  (a) Manoj keeps the branches independent and resolves on
      integration, which has to be done once, and once more for
      everytime that the context of either of the two patches
      changes.

  (b) I am experimenting by making the branches dependent on one
      another, thus resolving the conflict there once, and once
      more every time the context changes.

Manoj's branches are pristine in that they can be folded and
submitted upstream independently. This is not trivially possible
with my approach, and it's arguably a shortcoming. However, the
dependency is needed if you want to export a quilt series.

Manoj takes his approach further into debian/topics, which are
patches that are just like the branches independent of each other.
As such, they can be used independently and applied independently,
but you cannot use them to patch the upstream source without
resolving conflicts then. However, debian/topics is only a reference
and never used in the source package, because the Debian diff.gz
provides the complete patch across all topics, after Manoj did the
conflict resolution.

In the end, I don't think either approach requires more conflict
resolution than the other. The difference between them is that

  (a) Manoj provides you with the patched source and each topic
      patch nicely independent of each other, which serves two
      purposes: first, the patches document the features/fixes added
      to upstream, but they do not document how exactly the topics
      were combined to create the source. Second, the set of patches
      are against pristine upstream and can thus be independently
      used, which is convenient to those who want to pull single
      topics, but gets less convenient (but not less flexible) with
      increasing number of topics someone want to pull.

  (b) I provide the pristine source and a quilt series in
      debian/patches, which applies, and thus gives very specific
      information about how the upstream source gets altered before
      building the Debian package. The downside of this approach is
      that upstream (or another distribution) cannot trivially
      extract patches. If the feature branches are independent, then
      it's as easy as with Manoj's approach, since each patch in the
      quilt series can be applied by itself. If the features
      functionally depend on each other, e.g. B needed the
      infrastructure put in place by A, then it wouldn't make sense
      to obtain B independently anyway. But if A and B are
      functionally independent but simply overlap, then to obtain B,
      one has to subtract A, so it's less trivial to obtain
      B independently.

I think (b) is the compromise that serves me best. If I ever had an
A/B pair that are functionally independent, but which overlap, then
I could try to create a patch C, which makes trivial changes (like
adding a comment) so that A/B can depend on it and no longer overlap
as a result. Obviously, this is still not always possible.

-- 
 .''`.   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
 
"solange man nicht die moral des christentums
 als kapitalverbrechen am leben empfindet,
 haben dessen verteidiger gutes spiel."
                                                 - friedrich nietzsche
-------------- 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/20081123/ebda36ac/attachment-0001.pgp