Re: [PATCH 1/2] fetch/push: allow refs/*:refs/*
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 22, 2012, 11:28 UTC
- Message-ID
- <7v7gsrb1xs.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <50348C97.4040606@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 21 quoted lines
>> The remote side can also throw phony "I have this object, too, but
>> not at a particular ref---this entry is only to let you know I have
>> it, so that we can negotiate minimal transfer better" entries that
>> are labelled with strings that do not begin with "refs/" and do not
>> pass check_refname_format() (and because they are not refs, they do
>> not have to pass the test) at us, and we do not want to filter them
>> out in this function. But we do not want anything that is malformed
>> under "refs/".
>
> Thanks for the explanation. I'm trying to dig some more into this so
> that I can add some documentation, because this area of the code is
> rather obscure.
>
> Here is the loop being discussed, in full (from builtin/fetch-pack.c,
> filter_refs()):
> ...
> Empirically (determined by instrumenting the code and running the git
> test suite):
>
> * The first branch of the if statement is only executed for ref->name of
> the form "refs/tags/foo^{}" for various "foo".We do not want "fetch --mirror" and "refs/*:refs/*" to add a tag whose name is "foo^{}" to us.
> * The second branch of the if is *never* executed.
I am not familiar with (nor particularly interested in) the "args.depth" code, so I have no comment on this part offhand.
Show 6 quoted lines
> * The third branch is invoked for various reference names under "refs/" > (including oddballs like "refs/for/refs/heads/master", "refs/stash", > "refs/replace/<SHA1>"), and also for "HEAD". > > This doesn't quite agree with your explanation, because the phony refs > (at least in this dataset) *do* start with "refs/" and they *are* trashed.
Try fetching from a repository that has an alternate, and you would see those ".have" phoney refs.
But yes, they are trashed as well, as they are not likely to match, so you are right; the ".have" entries are red-herring (they have already been used before the caller calls this function for their sole purpose of marking the other side has).