Re: [RFC] revision: Add --sticky-default option

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 18, 2018, 06:59 UTC
Message-ID: <xmqqlg6vu4dw.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20181018064845.GB23537@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 10 quoted lines

> 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...

Show 12 quoted lines

> 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.