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