Re: [PATCH 02/38] rename_ref_available(): add docstring

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:

> From: David Turner <dturner@xxxxxxxxxxxxxxxx>
>
> Signed-off-by: David Turner <dturner@xxxxxxxxxxxxxxxx>
> Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
> Signed-off-by: Michael Haggerty <mhagger@xxxxxxxxxxxx>
> ---
>  refs/refs-internal.h | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/refs/refs-internal.h b/refs/refs-internal.h
> index efe5847..d8a2606 100644
> --- a/refs/refs-internal.h
> +++ b/refs/refs-internal.h
> @@ -240,6 +240,11 @@ const char *find_descendant_ref(const char *dirname,
>  				const struct string_list *extras,
>  				const struct string_list *skip);
>  
> +/*
> + * Check if the new name does not conflict with any existing refs
> + * (other than possibly the old ref).  Return 0 if the ref can be
> + * renamed to the new name.
> + */
>  int rename_ref_available(const char *oldname, const char *newname);

I do not quite understand the comment.  Partly because it is unclear
what "conflict" means here, but I guess it means a D/F conflict that
is explained near verify_refname_available()?

A new name can conflict with an existing, possibly old ref?  Are you
referring to this condition?

    You are trying to rename "refs/a/b" to "refs/a", which would
    conflict, but as long as there is no other ref that share the
    prefix "refs/a/", e.g. "refs/a/c", the new name "refs/a" is
    available.

I wonder if it is necessary to document that this function is not
meant to protect us from others racing with us.  That is, when you
are renaming something to "refs/a", you call this function and it
finds, by calling verify_refname_available(), that the repository
has nothing that conflicts with the name and says "OK", but before
you actually do the rename, somebody may push from sideways to
create "refs/a/b", making the result of an earlier check with this
function invalid.

Or is this to be called only under a lock that protects us from such
a race?
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]