Re: [StGIT RFC] Changing patch@branch syntax

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: May 22, 2007, 12:27 UTC
Message-ID: <b0943d9e0705220527x5d4c3d0fw2d0d66b37aab3f97@mail.gmail.com>
In-Reply-To: <20070515220310.GJ16903@nan92-1-81-57-214-146.fbx.proxad.net>

On 15/05/07, Yann Dirson <ydirson@altern.org> wrote:

Show 7 quoted lines

> 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.
>
> 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 that the current syntax is bad.

Show 7 quoted lines

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

We had a discussion some time ago about using slashes for the //top or //bottom syntax and we ended up using two slashes. We could do the same to delimitate the branch from the patch - branch//patch//top. The branch or patch can have (single) slashes in their name.

We couldn't use ":" at that time as it was used for the 'diff -r x:y' command. I later switched to the git ".." format (when git eventually defined it). As Karl said, branch:patch@top is another way, unless we later decide to add another level, the repository, and would like to have a uniform syntax (maybe always use ":" instead of "//"). We could run commands like:

  stg pick ../../path/to/linux-repo//branch//patch

I don't think using "#" is feasible as bash ignores everything after it unless you use quotes or escape.

Another nice thing to have is a way to get older versions of a patch via patchlogs. This should probably follow the current git notation, i.e. patch^^^ or patch~N.

-- 
Catalin