On Thu, 18 Oct 2018 at 08:59, Junio C Hamano <[email protected]> wrote:
> Jeff King <[email protected]> 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").
I agree, that's the kind of behavior I had in mind. (And I think
that's also what the code implements.)
> 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.
With positive selectors, it is meaningful if the selectors match
nothing. So in the above example, if jk/* matches nothing, I would
really expect no output, and the default should not be applied.
So we should just document that --default=<rev> only sets the default
in case the default is used.
> 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
Yes, it's a positive selector (since --not doesn't apply to --stdin).
> > # here we have no idea that the user did a query and must show HEAD
> > git log $(branches) --not origin/master
In this case, 'git log' is more used like git rev-list which doesn't
default to HEAD. The 'git log --no-default' would neatly restore
sanity here.
> 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.
Andreas
