Re: [StGIT RFC] Changing patch@branch syntax

Working in the implementation of hydras/pools, as well as discussing
of their future, led me to the following thoughts, quite related to
how we should select a new syntax for patches.

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.

Second, but not least, we currently have an ambiguity in syntax: "foo"
can mean "patch foo in current branch" or "branch foo", depending on
the context, and that is *really* bad.  What's more, my former
proposal (quoted below) does not improve this issue.  And my previous
proposal, which suggested using a prefix like "/stack/patch" for a
fully qualified patch and "patch" for a relative one does not solve
that problem either, and brings the additional annoyance of
introducing a syntax that is incompatible with git-core.

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)?)*

Examples:

	<stack>			the named branch (git-compatible)
	<stack>:<patch>		named patch in named stack
	:<patch>		named patch in current patchset (currently just "<patch>")
	<stack>:		current (top) patch in named patchset
	<pool>:<stack>:<patch>	fully-qualified patch in a named hydra
	::			top patch of the current stack of an hydra
	:<stack>://bottom.old	previous bottom of the top patch in the named stack of current pool


How does that feel ?


On Tue, May 22, 2007 at 11:00:20PM +0200, Yann Dirson wrote:

Following the "stg pick" example above, would we also want to allow
picking from a remote repo ?  Then the URL fragment notation could be
suited, and we could have something like:

	http://full/path/to/repo#my/branch:my/patch//top

That is, a formal syntax of:

	[[[repo#]branch:]patch][//modifier]

Going further, since specifying a repo without a branch probably has
no meaning (unless we want to default to the HEAD branch), we could
simplify to the following:

	[[[repo#]branch#]patch][//modifier]

I don't think we really want to allow "repo#patch", meaning that patch
on the current branch, as this gets easily confused by branch switching.