TopGit: problem with patch series generation

[Petr Baudis]

On Tue, Aug 12, 2008 at 08:10:37PM -0300, martin f krafft wrote:
> also sprach Petr Baudis <pasky at suse.cz> [2008.08.12.1959 -0300]:
> > How should that work? Maybe there needs to be even an explicit support
> > for this - should TopGit just check the dependency tree when
> > sequencing the topic branches and have a step that says:
> > 
> > 	"I'm going to sequence branch A. If there is branch T that has
> > 	only already sequenced branches + branch A as dependencies,
> > 	use T's content instead of A."
> > 
> > Would that be satisfactory?
> 
> Yes, that's what I was thinking about, if I read you correctly.

But we _REALLY_ want to do this only for stage branches!

> > Of course, in the case of
> > 
> >         A1--A2--A3--A4--C
> >                        /
> >         B1--B2--B3--B4.
> > 
> > the sequenced branches would still be like
> > 
> >         A1--A2--A3--A4--B1--B2--B3--C
> > 
> > unless you create the T1..T4 branches manually.
> 
> Yes. Or add a dependency. I'd just prefer not to add a dependency
> where there is none; instead, I'd prefer if TopGit could be aided
> with the serialisation in cases when it cannot possibly make
> a proper decision.

Yes, and it should certainly warn you about this at any rate, and give
you a chance to resolve this manually - possibly taking advantage of
rerere.

So, my idea: tg export --quilt should set up and maintain a private
working branch where it merges all the exported branches, one-by-one
(possibly doing the sling as described above first). In case there is a
conflict, it either aborts or gives you a chance to resolve it and go on
with the export. It could also offer you to save your resolution in a
new tie branch for future auto-slinging, but it would be tricky to
figure out exactly what patches does it depend on.

Overally, I'd start simply with implementing the sequential merge and
forget about slinging resolutions from tie branches. The former should
be very simple and solve most of the cases, especially when using rerere.
For the hairy cases, you can just add a dependency for now - sort of
preliminary serialization. :-)

The slinging might be feasible, but would be much more complicated
to implement. I think this can simply wait.

But to be clear, I don't plean to do any of this myself in the near
future anyway, since this case is not that important for me - I now need
TopGit to support remote topic branches instead. So if this is a
priority for you, you need to implement this on your own. But the
sequential merge part should be really easy, just something like

	git checkout -b tmp
	foreach patch_branch
		git merge patch_branch
		cat .topmsg >output/patch.diff
		git diff HEAD^..HEAD >>output/patch.diff

with all the frills. ;-) (Maybe make a special "show diff between X and
Y instead of base and head" flag for tg patch so that we can rely on it
for the frills.)

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates