config.txt: document the semantics of hideRefs with namespaces
Right now, there is no clear definition of how transfer.hideRefs should behave when a namespace is set. Explain that hideRefs prefixes match stripped names in that case. This is how hideRefs patterns are currently handled in receive-pack. Signed-off-by: Lukas Fleischer <lfleischer@lfos.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Lukas Fleischer committed
Nov 3, 2015 at 08:58 UTC
92cab492ba988ffd3e3edf040f19ba820306c833
1 file changed
+8
Documentation/config.txt
+8
@@ -2673,6 +2673,14 @@ You may also include a `!` in front of the ref name to negate the entry,
2673
explicitly exposing it, even if an earlier entry marked it as hidden.
2674
If you have multiple hideRefs values, later entries override earlier ones
2675
(and entries in more-specific config files override less-specific ones).
2676
++
2677
+If a namespace is in use, the namespace prefix is stripped from each
2678
+reference before it is matched against `transfer.hiderefs` patterns.
2679
+For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
2680
+the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
2681
+is omitted from the advertisements but `refs/heads/master` and
2682
+`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
2683
+"have" lines.
2684
2685
transfer.unpackLimit::
2686
When `fetch.unpackLimit` or `receive.unpackLimit` are