On 05/01/2015 07:21 PM, Stefan Beller wrote:
> On Fri, May 1, 2015 at 5:25 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote:
>> The reason why we can exit early if we find a reference in skip whose
>> name is a prefix of refname is a bit subtle, so explain it in a
>> comment.
>>
>> Signed-off-by: Michael Haggerty <mhagger@xxxxxxxxxxxx>
>> ---
>> refs.c | 14 +++++++++++++-
>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/refs.c b/refs.c
>> index 2bdd93c..ab438a5 100644
>> --- a/refs.c
>> +++ b/refs.c
>> @@ -907,8 +907,20 @@ static int is_refname_available(const char *refname,
>> pos = search_ref_dir(dir, refname, slash - refname);
>> if (pos >= 0) {
>> struct ref_entry *entry = dir->entries[pos];
>> - if (entry_matches(entry, skip))
>> + if (entry_matches(entry, skip)) {
>> + /*
>> + * The fact that entry is a ref whose
>> + * name is a prefix of refname means
>> + * that there cannot be any other ref
>> + * whose name starts with that prefix
>> + * (because it would have been a D/F
>> + * conflict with entry). So, since we
>> + * don't care about entry (because it
>> + * is in skip), we can stop looking
>> + * now and return true.
>
> At first I thought this is not true, what about:
> refs/heads/foo
> refs/heads/foobar
> They go well together and one is a prefix of the other.
> What is crucial is the existence of a '/' just between the
> prefix and the ending part, so
> refs/heads/foo/bar doesn't fly here.
>
> The assumption may be the case if the prefix itself always
> ends with a /, which is probably the case here?
> I don't know if that is worth noting as well.
Yes, this is all rather subtle. Here we have found a reference whose
name is *exactly* a proper prefix of refname; for example, refname is
"refs/foo/bar" and we just found "refs/foo". But "refs/foo" is in skip,
so it is not a conflict. Moreover, its existence means that there cannot
be any other references in the "refs/foo/*" namespace (e.g.,
"refs/foo/bar/banana") because such a reference would have conflicted
with "refs/foo".
If it's any consolation, this logic will be simplified a bit later in
the patch series. Nevertheless, I will try to explain this better in v2.
Michael
--
Michael Haggerty
mhagger@xxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html