Problem with "stgit show"

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