Lukas Fleischer <lfleisc...@lfos.de> writes:
> static void show_ref(const char *path, const unsigned char *sha1)
> {
> - if (ref_is_hidden(path))
> - return;
> -
> if (sent_capabilities) {
> packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
> } else {
> @@ -219,9 +216,14 @@ static void show_ref(const char *path, const unsigned
> char *sha1)
> }
> }
>
> -static int show_ref_cb(const char *path, const struct object_id *oid, int
> flag, void *unused)
> +static int show_ref_cb(const char *path_full, const struct object_id *oid,
> + int flag, void *unused)
> {
> - path = strip_namespace(path);
> + const char *path = strip_namespace(path_full);
> +
> + if (ref_is_hidden(path, path_full))
> + return 1;
> +
These two hunks are doing a bit more than the primary topic of this
step, aren't they?
The semantics of "hideRefs" used to be that "refs can be hidden from
ls-remote" (i.e. prevents fetching, avoids contaminating "--mirror")
and "refs can be hidden from 'push'", but the objects being known
tips of histories that are complete, they still participate in
common ancestor discovery.
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 3da97a1..91ed6a5 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -2690,7 +2690,8 @@ the prefix `refs/heads/master` is specified in
> `transfer.hideRefs` and the
> current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master` is
> omitted from the advertisements but `refs/heads/master` and
> `refs/namespaces/bar/refs/heads/master` are still advertised as so-called
> -"have" lines.
> +"have" lines. In order to match refs before stripping, add a `^` in front of
> +the ref name. If you combine `!` and `^`, `!` must be specified first.
I think the changes in the above two hunks prevent the hidden refs
from participating in common ancestor discovery (which is probably a
good thing), making the above description stale.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
