Re: [StGIT RFC] Changing patch@branch syntax

On 2007-05-16 00:03:10 +0200, Yann Dirson wrote:

The patch@branch syntax is annoying, at least for bash-completion
purposes: we don't want to provide all possible completions accross
all branches, yet we'd like to get completion for foreign patches.

Yes, that's annoying.

Another place where I feel it is bad is when using the full
"patch@branch//top" syntax: the MSB is in the middle, and the LSB is
on the right.

I agree. (Similarly, YYYYMMDD is the one true date format!)

Both issues would be solved by switching to a MSB ordering, with a
way to distinguish branchnames when given. Something similar to
pathnames would fit well - eg. [/branchname/]patchname[//top].
However, I'm not sure using slashes would be a good choice,
precisely because of the similarity with real pathnames. But we
don't have so many separator chars that are not special in one way
or another, and would require quoting them to avoid more user
confusion.

Branch names can contain slashes, and in the future patch names might
as well, so we'd need another separator. _Except_ for the fact that if
foo/bar is a branch, foo/bar/baz can't also be a branch, so using a
slash as separator is actually unambiguous.

If we similarly make it illegal for patches a/b and a/b/c to exist
simultaneously (whenever we get around to implementing slashy patch
names), we could use a single slash for patchname/{top,bottom} too.

The only remaining difficulty is to decide whether a/b/c is patch b/c
on branch a, or patch a/b/c on the current branch. We can't forbid
patch names and branch names to collide, since git can create new
branch names behind stgit's back. So I guess we'd need some way to
indicate whether branch name is included. The leading slash in your
suggestion seems as good a way as any.

However, I'm not going to recommend using only slashes. I believe life
will be much simpler if we simply use two different separators, like
this:

  branch:patch@top

Then all these subsets will be trivially parseable:

  branch:patch

  patch

  patch@top

And even this one, if we feel crazy some day:

  /path/to/other/repository#branch:patch@top

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle