Re: [StGIT RFC] Changing patch@branch syntax

From: Yann Dirson <ydirson@altern.org>
Date: Jun 22, 2007, 20:00 UTC
Message-ID: <20070622200037.GE7730@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <b0943d9e0706220859n2c2962ffy21464526a5ebd6cd@mail.gmail.com>

On Fri, Jun 22, 2007 at 04:59:05PM +0100, Catalin Marinas wrote:

Show 14 quoted lines

> >So here is a new proposal, which I believe would address all current
> >issues, at the expense of changing stgit syntax.  The idea is to use a
> >single separator for all levels of Stackable objects, with an optional
> >"patch id" (eg. //top) at the end when meaningful.  Only names would
> >be possible to omit, separators would be mandatory to specify the
> >nesting level.  That gives a syntax of:
> >
> >        [patchset]([:stackable]+(//id)?)*
> 
> I don't think I can write a regexp for it but I don't like the
> mandatory ":" before the patch name (or stackable object). The main
> reason is that one usually works on a branch with patch names, there
> might be scripts+xargs involved and forcing the use of ":" would make
> it more complicated.

That's probably not much of a problem: patch lists could be generated for script use with a flag similar to "series --showbranch".

Show 5 quoted lines

> 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.

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").

I'd rather having a single name-resolution mechanism, instead of one for patches and one for branches.

Show 14 quoted lines

> I'll try to express this with BNF (though I'm not an expert in this 
> notation):
> 
> <name> ::= "" | [^\w.-]+
> <attr> ::= top | top.old | bottom | bottom.old | log | ...
> <nameattr> ::= <name> | <name>//<attr>
> 
> <stackable> ::= <nameattr> | <stackable>:<stackable>
> 
> If empty name (""), the current object for the level is used.
> 
> The above <stackable> is more generic. A patchset might have other
> attributes or none at all (could have a "old" attribute if we decide
> to keep older versions of a stack for example).

Right, good idea.

> 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.

> but this is somehow at a similar level to <pool> in case we don't
> use a hydra. Or the <pool> can also be a repository?

I think they are different enough: a pool/hydra typically has several members applied, whereas a repo has only a current branch.

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 :)

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.

Did you have time to look at the various refactorings at http://repo.or.cz/w/stgit/ydirson.git ?

Best regards,

-- 
Yann