On 15/05/07, Yann Dirson <ydirson@xxxxxxxxxx> 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. 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.
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 - 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
