On 22/06/07, Yann Dirson <ydirson@xxxxxxxxxx> wrote:
On Fri, Jun 22, 2007 at 04:59:05PM +0100, Catalin Marinas wrote: > I also don't think we need to make this distinction in the names as > different commands or options take different type of arguments: > > stg show <patch> > stg series --branch <stack> Currently, "stg show HEAD" or any other git ref does work, except when there are name clashes.
But the argument to 'show' here is either a patch or a git ref (not a stack or a pool). It first tries to find a patch and fall back to a git ref. You don't specify a stack to 'show'. 'git show' is also able to take a commit or a tag object without clearly specifying the difference. What might be easier with a complete spec is bash completion. I find this mandatory precise description similar to the Hungarian notation. Since most of the time I work with push/pop commands, I don't like always putting a ":" for every patch (BTW, what about patch ranges, I don't think they can go across multiple stacks).
And since we're going to have all of patches, stacks, and pools in the same "stackable" family, we're going to use them interchangeably in more and more places. But there are also places where we can use at will stack names and generic git heads (eg. "stg branch X").
Currently, stack names and git branches are the same. Would this change with hydra? I use StGIT to maintain my branches on http://www.linux-arm.org/git?p=linux-2.6.git;a=heads and I find the stack name == git branch simplification pretty useful. What commands/options would we have where we need to distinguish between stack and patch names?
I'd rather having a single name-resolution mechanism, instead of one for patches and one for branches.
I don't see why we couldn't have a single name resolution but without the mandatory ":". An example (but in reverse order) is internet names. I only type "intranet" rather than "intranet." in a browser. To fully qualify, I type "intranet.arm.com".
> I would introduce a <repo> in front of all the above (for which we > don't have any support) Yes - URLs could do the work, with a '#' to use the stackable as URL fragment.
OK, you mentioned this in the past.
Now for technical details. I have a prototype hydra mechanism that demonstrates that we can create such a beast without having everything breaking all around. However, it does not use the model described in this thread, but rather links to stacks which exist independantly - I want to keep that as a possibility, by using some symlink-like mechanism, but the current prototype will not live, although I may experiment a bit more with it. BTW, we should probably name the final beast "pool" and not "hydra", so users have a better idea of how to use it :)
Yes, "pool" sounds better (though I didn't get the full idea of how things work).
However, the various refactorings and fixes I have done should be quite ready for inclusion (modulo dispatching recent fixes down to the relevant patch). Here I need to know your plans for 0.13: if the refactoring would go in, I just have to polish things as they are; if you prefer to keep this for 0.14, I'll sink the bugfixes down my stack so they can be in 0.13 at least.
I plan to do a 0.13 release pretty soon. I want to clear some of the logged bugs and release it as it seems to be pretty stable. It's better to keep this refactoring for 0.14. If it is easier for you, you could create a branch (for-upstream etc.) and just send me an email to merge it.
Did you have time to look at the various refactorings at http://repo.or.cz/w/stgit/ydirson.git ?
I had a quick look (not much though, moving house and a lot of FYI). They look OK, but just a few comments: - concreteCommand, I would write classes with capital first letter (unwritten convention in StGIT) - why the Repository class definition in stgit/__init__.py? Can it not be in a different file? Also, shourt stgit/git.py be aware of the repository? Regards. -- 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
