On Tue, Aug 12, 2008 at 08:10:37PM -0300, martin f krafft wrote: > also sprach Petr Baudis <pasky@xxxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
