Re: [PATCH] Allow hideRefs to match refs outside the namespace

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 1, 2015, 18:18 UTC
Message-ID: <xmqqy4ehh9c2.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20151101112716.3758.7843@typhoon.lan>

Lukas Fleischer <lfleischer@lfos.de> writes:

> Now, this cannot be intended behavior and I do not think this is
> something we want to retain when improving that feature.

Yup, that makes me suspect that namespace support with hiderefs was done without giving much thought even stronger than before, and the fact that nobody has brought it up so far suggests it would be much smaller deal than usual if a fix brings in incompatibilities to those who use namespaces.

Show 6 quoted lines

> 1. Define the (current) semantics of hideRefs pattern. It either needs
>    to be defined to match full references or stripped references. Both
>    definitions are equivalent when Git namespaces are not used.
>    
>    It probably makes sense to define hideRefs patterns to match stripped
>    references.

OK.

> 2. Improve the documentation and describe the hideRefs semantics better.
> 3. Fix the send_ref() code in either receive-pack or upload-pack,
> 4. Improve hideRefs patterns and allow to match both full references and
> 5. Add a note on the change in behavior to the release notes of the

All OK.

Show 13 quoted lines

> The second thing I noticed is that having syntax for allowing matches
> against both full references and stripped references is extremely handy
> and desirable, even if we would not have to introduce it for backwards
> compatibility. For example, using the syntax Junio described earlier, my
> initial use case could be solved by
>
>     receive.hideRefs=^refs/
>     receive.hideRefs=!refs/
>
> which means "Hide all references but do not hide references from the
> current namespace." Here, I am assuming that patterns for stripped refs
> never match anything outside the current namespace because those
> patterns become NULL after stripping.

I would instead assume that the presence of ^ (or !^) in front would signal "do not strip before checking". !refs/ would mean "after stripping, does it begin with refs/? If so then do not hide it".

But that does not change the conclusion. With ^refs/ that says "hide everything that matches refs/ before stripping" (i.e. do not include anything from anywhere), that is overriden by !refs/ that says "but do not hide anything that matches refs/ after stripping" (do include everything from my namespace), I'd think that you'd get your desired behaviour.

Thanks.