Re: TopGit: problem with patch series generation

From: Petr Baudis <pasky@suse.cz>
Date: Aug 13, 2008, 00:18 UTC
Message-ID: <20080813001809.GO10151@machine.or.cz>
In-Reply-To: <20080812231037.GC16481@lapse.rw.madduck.net>

On Tue, Aug 12, 2008 at 08:10:37PM -0300, martin f krafft wrote:

Show 12 quoted lines

> also sprach Petr Baudis <pasky@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!

Show 16 quoted lines

> > 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