From: "Catalin Marinas" <catalin.marinas@gmail.com>
To: "Yann Dirson" <ydirson@altern.org>
Cc: "GIT list" <git@vger.kernel.org>
Subject: Re: [StGIT RFC] Changing patch@branch syntax
Date: Fri, 22 Jun 2007 16:59:05 +0100 [thread overview]
Message-ID: <b0943d9e0706220859n2c2962ffy21464526a5ebd6cd@mail.gmail.com> (raw)
In-Reply-To: <20070621230207.GD7730@nan92-1-81-57-214-146.fbx.proxad.net>
On 22/06/07, Yann Dirson <ydirson@altern.org> wrote:
> 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).
> 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):
<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).
In terms of our patches, stacks etc.:
<pool> ::= <name>
<stack> ::= <name> | <pool>:<name>
<patch> ::= <nameattr> | <stack>:<nameattr>
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
next prev parent reply other threads:[~2007-06-22 15:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-15 22:03 [StGIT RFC] Changing patch@branch syntax Yann Dirson
2007-05-16 6:54 ` Karl Hasselström
2007-05-22 12:27 ` Catalin Marinas
2007-05-22 21:00 ` Yann Dirson
2007-06-21 23:02 ` Yann Dirson
2007-06-22 15:59 ` Catalin Marinas [this message]
2007-06-22 20:00 ` Yann Dirson
2007-06-22 22:29 ` Catalin Marinas
2007-06-24 21:26 ` Yann Dirson
2007-06-25 22:22 ` Catalin Marinas
2007-06-26 22:31 ` Yann Dirson
2007-07-06 22:04 ` [StGIT RFC] Changing patch@branch syntaxtackable> ::= <nameattr> | <stackable>:<stackable> Yann Dirson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b0943d9e0706220859n2c2962ffy21464526a5ebd6cd@mail.gmail.com \
--to=catalin.marinas@gmail.com \
--cc=git@vger.kernel.org \
--cc=ydirson@altern.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).