Re: [PATCH 2/2] refs: support negative transfer.hideRefs

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> If you hide a hierarchy of refs using the transfer.hideRefs
> config, there is no way to later override that config to
> "unhide" it. This patch implements a "negative" hide which
> causes matches to immediately be marked as unhidden, even if
> another match would hide it. We take care to apply the
> matches in reverse-order from how they are fed to us by the
> config machinery, as that lets our usual "last one wins"
> config precedence work (and entries in .git/config, for
> example, will override /etc/gitconfig).
>
> There are two alternatives that were considered and
> rejected:
> ...
>   1. A generic config mechanism for removing an item from a
>      ...
>   2. Adding another variable to override some parts of
>      ...
>      Of course we could internally parse that to a single
>      list, respecting the ordering, which saves us having to
>      invent the new "!" syntax. But using a single name
>      communicates to the user that the ordering _is_
>      important. And "!" is well-known for negation, and
>      should not appear at the beginning of a ref (it is
>      actually valid in a ref-name, but all entries here
>      should be fully-qualified, starting with "refs/").

I notice that the only time you said that you chose '!' prefix as
the way to express this new "negative" is as a side note to the
rejected second variant ;-).  The first paragraph would have been a
good place to say that, because the first thing I wondered after
reading three lines (including the subject) into the log was "ok, it
makes sense and I know what alternatives were considered and
discarded for what reasons without reading the rest, now did he use
prefix '-', prefix '~', prefix '^', or prefix '!' for the new
syntax, or did he use something else?"

It would have been very nice if you chose an invalid ref character
as the negative prefix, and unfortunately '!', which would also have
been my first choice for this prefix, is not an invalid character,
which is a bit sad.

Both patches make sense.  Will queue.

Thanks.