A (git) workflow for Debian packaging

[Sam Vilain]

martin f krafft wrote:
> The reasons are outlined in the above thread. Basically it's because
> I cannot use the octopus merge strategy as it is if any of the
> branches modified files that are known to the other branches, and
> I modified files like .gitignore or debian/postinst in master, but
> obviously not in deb/*.
> 
> If I first merge master, then deb/*, it works, simply because then
> git gets to use its infinitely smarter recursive merge strategy.
> 
> If I merge master into deb/* before the octopus, it should also
> work.

You can create octopus merges that contain real merges, but this was
just considered too much of a headf*ck to let you do it easily.

> But I fear that this gets a little complicated and requires too much
> brain power from the operator.
> 
> I shall thus try to figure out a better way to automate this. Good
> thing I haven't published the text yet to the wider audience.

ok, so to make an octopus merge that isn't just a simple index merge;
(one approach)

1. get a list of all of the heads that you want to merge

2. merge them one at time in, committing along the way so that the next
merge (and git-mergetool etc) will work

3. once you've resolved all the merges, save the resultant tree ID,
reset (--mixed) to one of the original heads, use "read-tree" to set the
index to the merge result, then "commit-tree -p XXX -p XXX" to make the
merge commit.  The original merges will be discarded (that is, exist
only in the reflog and be eventually reaped by the gc).

Sam.