On 15/06/07, Yann Dirson <ydirson@xxxxxxxxxx> wrote:
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 :)
If you can track the patch dependencies, it would be enough to no longer have a stack but a pool of patches (like darcs but without exact patch commuting, the diff3 merging provides a good approximation of this operation and in a much faster time). Simple patch dependency could be detected by trying to apply a patch without others (it can be optimised so that only patches touching common files should be checked).
> 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.
But the 'stg mail' command already adds a "From:" line in the body (with the default template) and 'import' checks for 'From:' or 'Author:' which override the e-mail sender. You might be using a different e-mail template. -- Catalin - 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
