Debian packaging with git and conflicts resolution

[Russ Allbery]

martin f krafft <madduck at debian.org> writes:
> also sprach Russ Allbery <rra at stanford.edu> [2008.11.18.0056 +0100]:

>> Rather than using rerere, I create a temporary merge branch based off
>> upstream and merge each topic branch into it in sequence, and then
>> merge the temporary merge branch into the integration branch, which
>> seems to accomplish the same thing (not having to re-handle the merge
>> conflicts when merging the first topic branch).

> I cannot really explain this, because Git wouldn't really care, it only
> tracks content, so if there is a conflict, there is a conflict, and I
> can hardly imagine how to work around it. Maybe you're just lucky?

> Could you show us an example which works around a conflict that
> would otherwise exist?

I'm probably just not explaining it well.

Suppose you have a package with several separate bug fix topic branches
(call them A, B, and C) and an integration branch that has all of A, B,
and C merged into it.  A new upstream is released.

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.

Now, having finished that work, you merge A into your integration branch.
But A has been merged with upstream, so it has all of upstream's changes,
including the changes related to B and C.  Since your integration branch
still has the old versions of your B and C fixes, this merge creates
conflicts in your integration branch (the same conflicts that you just
fixed when you merged upstream into B and C).

If you instead do:

    git checkout -b tmp-merge upstream
    git merge A
    git merge B
    git merge C
    git checkout master
    git merge tmp-merge

everything works properly.  The tmp-merge branch doesn't have this problem
since it's branched off upstream and doesn't have your old B and C
branches merged, and by the time you merge tmp-merge into master, you have
all of your conflicts resolved already and the merge goes smoothly.

I ran into that exact problem with shibboleth-sp and shibboleth-sp2.

As Manoj points out, this only works if A, B, and C don't conflict with
each other.  If they do, you probably want to just use rerere.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>