Jeff King <peff@xxxxxxxx> writes:
> Just to play devil's advocate, how about this:
>
> git log --branches=jk/* --not origin/master
>
> Right now that shows nothing if there are no matching branches. But I
> think under the proposed behavior, it would start showing HEAD, which
> seems counter-intuitive.
>
> Or are we going to count any positive selector as a positive ref, even
> if it matches nothing?
That sounds like an intuitive behaviour of the command, but I may
change my mind when I look at other examples.
When viewing that "--branches=jk/*" example in isolation, yes, these
positive selectors that could produce positive revs should defeat
the --default, especially when it is built-in (like "log"). When
given by the user, I am not sure. With something like this:
git rev-list --default=HEAD --branches=jk/* ^master
clearly the user anticipates that jk/* may or may not produce any
positive refs; otherwise there is no point specifying the default.
But anyway...
> I could buy that, though it means that the
> command above is subtly different from one or both of:
>
> branches() {
> git for-each-ref --format='%(refname)' refs/heads/jk/*
> }
>
> # is --stdin a selector, too?
> branches | git log --stdin --not origin/master
>
> # here we have no idea that the user did a query and must show HEAD
> git log $(branches) --not origin/master
OK, scrap that---just as I predicted a few minutes ago, I now think
that "do we have a positive selector that can produce zero or more
result?" is an ill-defined question X-<.
Thanks for a doze of sanity.
