Re: [StGIT RFC] Changing patch@branch syntaxtackable> ::= <nameattr> | <stackable>:<stackable>

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



My thoughts about stg-show suggested me we can extend on the latest
proposed syntax, by allowing comma-separated sequences of patch
ranges.  Such ranges would not be limitted to patches either, they
would be meaningful within any patchset (or maybe within ordered
patchsets only, should we feel this restriction necessary).  Eg:

	stg show <pool>:<stack>:foo,bar..buz

Patch attributes OTOH probably don't play well with ranges - which I
take as a symptom that we should be careful about them.

We may also want to generalize the patch//attribute mechanism a bit
more, eg. so "base" is not seen as a fake patch, but rather an
attribute of the patchset.  That is, something like
"<pool>:<stack>//base" should be a valid id.

Let's try to get a full formal syntax, based on the one you formerly
proposed.

    <name> ::= [^\w.-]+
    <attr> ::= 'top' | 'top.old' | 'bottom' | 'bottom.old' | 'log' | ...
    <patchname>|<stackname>|<poolname>|<hydraname> ::= <name>
    <patchsetname> ::= <stackname> | <poolname> | <hydraname>

    <patchset> ::= <patchsetname> ? | <patchset> ':' <patchsetname> ?
    <patch> := <patchset> ':' <patchname>

    <commitid> ::= ( <patch> | <patchset> ) ? '//' <attr>

    <simplerange0> ::= <name> | <name> '..' <name>? | '..' <name>
    <simplerange> ::= <simplerange> | <simplerange0> ',' <simplerange>

    <range> := <patchset> ':' <simplerange>


On Wed, Jun 27, 2007 at 12:31:43AM +0200, Yann Dirson wrote:
> On Mon, Jun 25, 2007 at 11:22:15PM +0100, Catalin Marinas wrote:
> > 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.

Given the complexity of the approaches I proposed, we may want to keep
an "hydra" type besides "pools".  After all, we may implement as many
PatchSet subclasses we can think of :)

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux