Re: [PATCH 02/38] rename_ref_available(): add docstring
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 7, 2016, 18:10 UTC
- Message-ID
- <xmqq7fe0rhts.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <5eb96cc20c0f76aff39d1556803ebd4f9f422cea.1464983301.git.mhagger@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 23 quoted lines
> From: David Turner <dturner@twopensource.com> > > Signed-off-by: David Turner <dturner@twopensource.com> > Signed-off-by: Junio C Hamano <gitster@pobox.com> > Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> > --- > 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?