On Mon, Jun 25, 2007 at 11:22:15PM +0100, Catalin Marinas wrote: > >I have often wondered if it would be useful to have a given > >patch@stack as a base for another stack, or maybe as one of the > >"heads" of an hydra. Still not sure it would make any sense, however > >- especially, proper use of hydras would possibly suppress the need > >for the former. > > There are situations when I want a separate branch but it relies on > patches in other branches. I currently duplicate the patches and use > the 'sync' command to keep them up to date (though this command would > be more useful with support for git-rerere to avoid fixing the same > conflict several times). > > Can a patch series be part of multiple pools? This would be useful to > my workflow. In the current prototype, yes, since the current "hydra" object only binds existing stacks. In the design we've discussed, not directly - let's find a solution. My idea of what we've discussed most recently is that stackables will be *contained* in patchsets. Ie. a pool will be able to contain both patches-as-we-know-them, and stacks, but those stacks won't be git heads, only refs in a namespace still to be decided upon - something similar to how we currently store patch refs. To allow sharing a stack between several pools, I can see 2 options. The easiest to implement (but not necessarily the easiest to live with) is to clone and sync the stack. Another one is to add another Stackable subclass (eg. StackableLink), that would figure some sort of symbolic link to the reference Stackable. It would provide in the current patchset a local name for the linked Stackable, but may need to be more than a simple alias: a pool is, at least for now, an octopus, and thus only supports conflict-less members; thus, if the linked Stackable changes to be incompatible with the link siblings, the patchset containing the conflict would instantly become invalid. Either we add support for this "invalidated" status, or we find a better way. One possibility I thought of, is that the link will point a specific version of its referenced stackable (a point always reachable from new versions of the referenced stackable through its patch/ref/stack/whatever-log), and the user will need to explicitely stg-pull to get the new version, with the option to "pull --undo" if he does not like it. All these options leave room for innovative workflows :) > >In current StGIT, in cases where > >"name" matches both a local patch a git ref... well, we can still ask > >for refs/heads/name as fully-qualified name - looks like I had > >forgotten that one ;) > > StGIT could default to patches and fall back to git commits if no ":" > are found in the name. I'd rather leave this fallback to the minimum (esp. if only "show" and "pick" can make sense out of it). > >I consider we have a couple of special cases: > > > > clean currently does not care, but see task #5235 > > rebase currently only needs patchets, do we need to extend that to > > patches ? > > 'rebase' could only work on the current patchset because of the > possibility of getting conflicts during push (unless you implement the > branch switching as well). That's not what I was thinking about. I was mentionning the possibility to rebase to a given patch, so "pull" will follow later versions of that patch. Not sure it is useful, though, and it can probably already be done by rebasing to refs/patches/<branch>/<patch> (although that accesses implementation details, that rebasing to <branch>:<patch> would not need to). > > new creates a patch in the current stack, we may want to unify > > this with "branch -c" in some way (maybe "stg > > (patch|stack|pool) new" ?) > > This might be a possibility once we refactor the command line. Right - that was subliminally suggesting to refactor the command-line before 1.0, in fact ;) > >> Also, shourt stgit/git.py be aware of the repository? > > > >I'd rather think that we should have git.Repository (and further > >structurate git.py with more objects, like git.Branch), with > >stgit-specific stuff in the stgit.Repository subclass. > > Sounds good. Cool. 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
