While investigating bug #8453 (https://gna.org/bugs/?8453) I looked for the 1st time at how "stg show" is implemented, and it looks like this and a couple of related parts of the code need some refactoring. The problem is, "stg show a@b" and "stg show a@b z@b" trigger different code paths. The problem with the latter is that, having more than one arg, it gets feed through parse_patches(), which is only designed to deal with patches in a single stack, and rejects "a@b" as not a member of the current stack. The single-arg form, at the opposite, falls into the branch designed to emulate "git show" by allowing git refs not otherwise meaningful to stgit. That is, "stg show a@b" seems to only work as a side-effect. The same difference in handling single-arg from multiple-arg will similarly cause non-stgit refs to be invalid when not given alone (ie. "stg show origin/master" works, but "stg show origin/master patch1" fails with "Unknown patch name: origin/master". Since the different handling of len(args)==1 results in inconsistencies, IMHO we should get rid of it. Now adding support for out-of-this-stack refs to parse_patches() would require a total rewrite thereof, so I suggest we leave this for another round. Non-stgit refs should IMHO be dropped. Catalin, you mentionned consistency with "stg pick" IIRC, but "pick" only ever takes a single arg, so the commands are clearly too different. We always have git-show anyway if we want to look at them. For patches on other branches, we could simply add the common --branch flag to "stg show". That would not allow to get patches from different stacks in a single run, and it's a bit more verbose than the @ syntax for a single patch, but well, that could make sense for 0.13. I'll send out a couple of patchlets for this. -- Yann - 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
