Re: [StGIT RFC] Changing patch@branch syntax

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Jun 22, 2007, 15:59 UTC
Message-ID: <b0943d9e0706220859n2c2962ffy21464526a5ebd6cd@mail.gmail.com>
In-Reply-To: <20070621230207.GD7730@nan92-1-81-57-214-146.fbx.proxad.net>

On 22/06/07, Yann Dirson <ydirson@altern.org> wrote:

Show 6 quoted lines

> First, as a foreword, a bit if refactoring: I think we should use some
> sort of Stackable (maybe pick a better name) class as a parent for
> Patch and PatchSet.  Instances of a Stackable would be candidates to
> be members of a PatchSet.  That means we can have stacks within a
> stack, as well as stacks members of a pool.  But we also need a syntax
> to name stacks-(in-a-stack)*, and patches within them.

I'm OK with refactoring the code this way (the current code is based on the initial prototype but it evolved a lot since then).

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

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>

I'll try to express this with BNF (though I'm not an expert in this notation):

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

In terms of our patches, stacks etc.:

I would introduce a <repo> in front of all the above (for which we don't have any support) 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?

> Examples:
>
>         <stack>                 the named branch (git-compatible)

<patch> - named patch in the current patchset

>         <stack>:<patch>         named patch in named stack

OK

>         :<patch>                named patch in current patchset (currently just "<patch>")

OK, the same as <patch>

>         <stack>:                current (top) patch in named patchset

OK (maybe use should use "current" rather than "top" in the description as it applies better to other stackable objects)

>         <pool>:<stack>:<patch>  fully-qualified patch in a named hydra

OK

>         ::                      top patch of the current stack of an hydra

OK (current patch of the current stack)

>         :<stack>://bottom.old   previous bottom of the top patch in the named stack of current pool

OK

-- 
Catalin