Re: [PATCH 02/18] is_refname_available(): explain the reason for an early exit

From: Stefan Beller <sbeller@google.com>
Date: May 1, 2015, 17:21 UTC
Message-ID: <CAGZ79kZDCMj1P1H3+LiW-Lk8S8TS91yJ_G4scmVSvg++3n7dvw@mail.gmail.com>
In-Reply-To: <1430483158-14349-3-git-send-email-mhagger@alum.mit.edu>

On Fri, May 1, 2015 at 5:25 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:

Show 29 quoted lines

> 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@alum.mit.edu>
> ---
>  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.

Show 9 quoted lines

> +                                */
>                                 return 1;
> +                       }
>                         report_refname_conflict(entry, refname);
>                         return 0;
>                 }
> --
> 2.1.4
>