On Thu, Jun 14, 2007 at 11:56:47PM +0100, Catalin Marinas wrote: > On 13/06/07, Yann Dirson <ydirson@xxxxxxxxxx> wrote: > >I have started to work on a Hydra class (available at [1], but be > >aware it doesn't do much more than creating an octopus, and breaking > >many current StGIT assumptions), with a testcase to demonstrate its > >use), which binds together a set of stacks with an octopus, to allow > >keeping related patches together, and allow people to pull from one > >topic stack without getting unrelated work. > > If it works, it would be really useful. Do the stacks need to be > independent? I can group my patches easily (and I was thinking about > "collapse/expand" commands for better viewing) but one stack might > still depend on patches from a different one. It would be nice if one > could also set the base of a series in this kind of hydra structure > (unless it makes it difficult to understand). Indeed one of the things that naturally come to mind after hydra, is to abstract a parent class above PatchSet and Patch, and allow those to be mostly used everywhere one of them is allowed. That way we can have a (sub-)stack anywhere between 2 patches in a stack, and that should I think address the need you describe. But that would also allow to have an hydra built of single patches instead of stacks, which would be quite similar to how darcs organizes patches. Combinations are endless, and I don't even count the possibility of adding new structures besides stacks and hydras :) > >As described in that mail, there are problems both with the > >original approach (Karl's test failing), and with that new one (that > >exisiting test failing). > > > >Do you have any idea on how we could overcome the problem ? In the > >meantime, we could possibly just comment that testcase out (or add > >support for continuing the testsuite even with a failure) - the > >problem it exhibits is probably less common than the one that was > >fixed. > > I am happy with only 2 modes - one using ORIG_HEAD for people using > StGIT in combination with plain GIT and the other overriding the base > without checks. The second mode is for people not mixing StGIT with > plain GIT. For the first mode, they have to deal with conflicts as > with the standard GIT. Well, I have to think about that in details - but right now I'm a bit busy with the hydra thing. > >BTW, a02ba4077f12578fe31c99d903488804a656e1c4 has a slight problem: it > >is a patch by Karl, which I re-sent in the same group since it was > >exhibiting the problem (and with the intent of adding a signed-off-by > >line, but my way of adding them trough a buggy template showed its > >limits and the commit now have 2 signed-off-by lines with Karl's > >name). However, it was applied with myself as author, which is quite > >wrong: could that be a but in "stg import" ignoring the Author field ? > > It's not a bug. The import command just uses the e-mail sender or a > "From:" line before the patch description (see the default mail > template). It doesn't check the sign lines (it is following the kernel > patch submission guidelines). We could surely improve things (and I'm not suggesting we should look at sign lines). Eg, by having stg-mail add an Author pseudo-header when the patch author is different from the sender, and having stg-import use that when available. > I would drop both the above commits for release 0.13. Are you OK with this? Seems reasonable: the previous situation only seems to hurt when using a workflow not involving stgit alone, whereas with this patch we also break stgit-only workflows. Best regards, -- Yann. - 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
