Re: [PATCH] builtin-symbolic-ref: comment on the use of "resolve_ref" with reading == 0

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

 



Christian Couder <chriscool@xxxxxxxxxxxxx> writes:

> diff --git a/builtin-symbolic-ref.c b/builtin-symbolic-ref.c
> index bfc78bb..9490c47 100644
> --- a/builtin-symbolic-ref.c
> +++ b/builtin-symbolic-ref.c
> @@ -12,6 +12,16 @@ static void check_symref(const char *HEAD, int quiet)
> ...
> +	/*
> +	 * It doesn't seem logical to use "resolve_ref" with reading == 0
> +	 * as we are just checking if a ref exists,...
> ...
> +	 */

I have to say that this comment is confused.

When you have a full ref (as opposed to an abbreviated one that you might
give to dwim_ref()), you can use it for two kinds of things:

 (1) You can use it to find out what _object_ the ref points at.  This is
     "reading" the ref, and the ref, if it is not symbolic, has to exist,
     and if it is symbolic, it has to point at an existing ref, because
     the "read" goes through the symref to the ref it points at.

 (2) Anything else.  This could be a prelude to "writing" to the ref, in
     which case a write to a symref that points at yet-to-be-born ref will
     create the real ref pointed by the symref, so such a symref is not an
     error.  It has to answer "here is the real ref you should write into"
     (or, "we will write into").

     But the access that is not "reading" does not have to be "writing";
     it can be merely checking _where it leads to_.  And check_symref()
     uses this call for exactly that purpose.  This access is not
     "checking if a ref exists".

So reading==0 is the logical thing to do here.
--
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]

  Powered by Linux