Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

show-ref: add --symbolic-name option #1684

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

john-cai
Copy link
Contributor

@john-cai john-cai commented Mar 4, 2024

For reftable development, it would be handy to have a tool to provide the direct value of any ref whether it be a symbolic ref or not. Currently there is git-symbolic-ref, which only works for symbolic refs, and git-rev-parse, which will resolve the ref. Let's add a --symbolic-name option that will print out the value the ref directly points to without dereferencing it.

Changes since V1:

  • changed output format to print out values as a third column
  • made plumbing changes to enable the value of a symbolic ref to be read from the iterator
  • changed the name of the flag

cc: Phillip Wood [email protected]
cc: "Kristoffer Haugsbakk" [email protected]
cc: Jeff King [email protected]
cc: Patrick Steinhardt [email protected]
cc: Jean-Noël Avila [email protected]

@john-cai
Copy link
Contributor Author

john-cai commented Mar 4, 2024

/preview

Copy link

Preview email sent as [email protected]

@john-cai
Copy link
Contributor Author

john-cai commented Mar 4, 2024

/submit

Copy link

Submitted as [email protected]

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-git-1684/john-cai/jc/show-ref-direct-v1

To fetch this version to local tag pr-git-1684/john-cai/jc/show-ref-direct-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-git-1684/john-cai/jc/show-ref-direct-v1

Copy link

On the Git mailing list, Junio C Hamano wrote (reply to this):

"John Cai via GitGitGadget" <[email protected]> writes:

> From: John Cai <[email protected]>
>
> For reftable development, it would be handy to have a tool to provide
> the direct value of any ref whether it be a symbolic ref or not.
> Currently there is git-symbolic-ref, which only works for symbolic refs,
> and git-rev-parse, which will resolve the ref. Let's add a --unresolved
> option that will only take one ref and return whatever it points to
> without dereferencing it.

The approach may be reasonble, but the above description can use
some improvements.

 * Even though the title of the patch says show-ref, the last
   sentence is a bit too far from there and it was unclear to what
   you are adding a new feature at least to me during my first read.

      Let's teach show-ref a `--unresolved` optionthat will ...

   may make it easier to follow.

 * "Whatever it points to without dereferencing it" implied that it
   assumes what it is asked to show can be dereferenced, which
   invites a natural question: what happens to a thing that is not
   dereferenceable in the first place?  The implementation seems to
   show either symbolic-ref target (for symbolic refs) or the object
   name (for others), but let's make it easier for readers.

>  Documentation/git-show-ref.txt |  8 ++++++
>  builtin/show-ref.c             | 33 ++++++++++++++++--------
>  t/t1403-show-ref.sh            | 47 ++++++++++++++++++++++++++++++++++
>  3 files changed, 77 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
> index ba757470059..2f9b4de1346 100644
> --- a/Documentation/git-show-ref.txt
> +++ b/Documentation/git-show-ref.txt
> @@ -16,6 +16,7 @@ SYNOPSIS
>  	     [--] [<ref>...]
>  'git show-ref' --exclude-existing[=<pattern>]
>  'git show-ref' --exists <ref>
> +'git show-ref' --unresolved <ref>
>  
>  DESCRIPTION
>  -----------
> @@ -76,6 +77,13 @@ OPTIONS
>  	it does, 2 if it is missing, and 1 in case looking up the reference
>  	failed with an error other than the reference being missing.
>  
> +--unresolved::
> +
> +	Prints out what the reference points to without resolving it. Returns
> +	an exit code of 0 if it does, 2 if it is missing, and 1 in case looking
> +	up the reference failed with an error other than the reference being
> +	missing.

Exactly the same issue as in the proposed log message, i.e. what is
printed for what kind of ref is not really clear.

> -static int cmd_show_ref__exists(const char **refs)
> +static int cmd_show_ref__raw(const char **refs, int show)
>  {
> -	struct strbuf unused_referent = STRBUF_INIT;
> -	struct object_id unused_oid;
> -	unsigned int unused_type;
> +	struct strbuf referent = STRBUF_INIT;
> +	struct object_id oid;
> +	unsigned int type;
>  	int failure_errno = 0;
>  	const char *ref;
>  	int ret = 0;
> @@ -236,7 +237,7 @@ static int cmd_show_ref__exists(const char **refs)
>  		die("--exists requires exactly one reference");
>  
>  	if (refs_read_raw_ref(get_main_ref_store(the_repository), ref,
> -			      &unused_oid, &unused_referent, &unused_type,
> +			      &oid, &referent, &type,
>  			      &failure_errno)) {
>  		if (failure_errno == ENOENT || failure_errno == EISDIR) {
>  			error(_("reference does not exist"));
> @@ -250,8 +251,16 @@ static int cmd_show_ref__exists(const char **refs)
>  		goto out;
>  	}
>  
> +		if (!show)
> +			goto out;
> +
> +		if (type & REF_ISSYMREF)
> +			printf("ref: %s\n", referent.buf);
> +		else
> +			printf("ref: %s\n", oid_to_hex(&oid));

If I create a symbolic ref whose value is deadbeef....deadbeef 40-hex,
I cannot tell from this output if it is a symbolic ref of a ref that
stores an object whose name is that hash.  Reserve the use of "ref: %s"
to the symbolic refs (so that it will also match how the files backend
stores them in modern Git), and use some other prefix (or no
perfix).

Actually, I am not sure if what is proposed is even a good
interface.  Given a repository with these few refs:

    $ git show-ref refs/heads/master
    b387623c12f3f4a376e4d35a610fd3e55d7ea907 refs/heads/master
    $ git show-ref refs/remotes/repo/HEAD
    b387623c12f3f4a376e4d35a610fd3e55d7ea907 refs/remotes/repo/HEAD
    $ git symbolic-ref refs/remotes/repo/HEAD
    refs/remotes/repo/master

I would think that the second command above shows the gap in feature
set our current "show-ref" has.  If we could do

    $ git show-ref --<option> refs/heads/master refs/remotes/repo/HEAD
    b387623c12f3f4a376e4d35a610fd3e55d7ea907 refs/heads/master
    ref:refs/remotes/repo/master refs/remotes/repo/HEAD

or alternatively

    $ git show-ref --<option> refs/heads/master refs/remotes/repo/HEAD
    b387623c12f3f4a376e4d35a610fd3e55d7ea907 refs/heads/master
    ref:refs/remotes/repo/master b387623c12f3f4a376e4d35a610fd3e55d7ea907 refs/remotes/repo/HEAD

wouldn't it match the existing feature set better?  You also do not
have to limit yourself to single ref query per process invocation.

I am not sure if you need to worry about quoting of the values of
symbolic-ref, though.  You _might_ need to move the (optional)
symref information to the end, i.e. something like this you might
prefer.  I dunno.

    $ git show-ref --<option> refs/remotes/repo/HEAD
    b387623c12f3f4a376e4d35a610fd3e55d7ea907 refs/remotes/repo/HEAD refs/remotes/repo/master 

I do not know what the <option> should be called, either.  From an
end-user's point of view, the option tells the command to also
report which ref the ref points at, if it were a symbolic one.
"unresolved" may be technically acceptable name to those who know
the underlying implementation (i.e. we tell read_raw_ref not to
resolve when it does its thing), but I am afraid that is a bit too
opaque implementation detail for end-users who are expected to learn
this option.

Copy link

On the Git mailing list, Phillip Wood wrote (reply to this):

Hi John

On 04/03/2024 22:51, John Cai via GitGitGadget wrote:
> From: John Cai <[email protected]>
> > For reftable development, it would be handy to have a tool to provide
> the direct value of any ref whether it be a symbolic ref or not.
> Currently there is git-symbolic-ref, which only works for symbolic refs,
> and git-rev-parse, which will resolve the ref. Let's add a --unresolved
> option that will only take one ref and return whatever it points to
> without dereferencing it.

"--unresolved" makes me think of merge conflicts. I wonder if "--no-dereference" would be clearer.

Best Wishes

Phillip

> Signed-off-by: John Cai <[email protected]>
> ---
>      show-ref: add --unresolved option
>      >      For reftable development, it would be handy to have a tool to provide
>      the direct value of any ref whether it be a symbolic ref or not.
>      Currently there is git-symbolic-ref, which only works for symbolic refs,
>      and git-rev-parse, which will resolve the ref. Let's add a --unresolved
>      option that will only take one ref and return whatever it points to
>      without dereferencing it.
> > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1684%2Fjohn-cai%2Fjc%2Fshow-ref-direct-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1684/john-cai/jc/show-ref-direct-v1
> Pull-Request: https://github.com/git/git/pull/1684
> >   Documentation/git-show-ref.txt |  8 ++++++
>   builtin/show-ref.c             | 33 ++++++++++++++++--------
>   t/t1403-show-ref.sh            | 47 ++++++++++++++++++++++++++++++++++
>   3 files changed, 77 insertions(+), 11 deletions(-)
> > diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
> index ba757470059..2f9b4de1346 100644
> --- a/Documentation/git-show-ref.txt
> +++ b/Documentation/git-show-ref.txt
> @@ -16,6 +16,7 @@ SYNOPSIS
>   	     [--] [<ref>...]
>   'git show-ref' --exclude-existing[=<pattern>]
>   'git show-ref' --exists <ref>
> +'git show-ref' --unresolved <ref>
>   >   DESCRIPTION
>   -----------
> @@ -76,6 +77,13 @@ OPTIONS
>   	it does, 2 if it is missing, and 1 in case looking up the reference
>   	failed with an error other than the reference being missing.
>   > +--unresolved::
> +
> +	Prints out what the reference points to without resolving it. Returns
> +	an exit code of 0 if it does, 2 if it is missing, and 1 in case looking
> +	up the reference failed with an error other than the reference being
> +	missing.
> +
>   --abbrev[=<n>]::
>   >   	Abbreviate the object name.  When using `--hash`, you do
> diff --git a/builtin/show-ref.c b/builtin/show-ref.c
> index 1c15421e600..58efa078399 100644
> --- a/builtin/show-ref.c
> +++ b/builtin/show-ref.c
> @@ -18,6 +18,7 @@ static const char * const show_ref_usage[] = {
>   	   "             [--] [<ref>...]"),
>   	N_("git show-ref --exclude-existing[=<pattern>]"),
>   	N_("git show-ref --exists <ref>"),
> +	N_("git show-ref --unresolved <ref>"),
>   	NULL
>   };
>   > @@ -220,11 +221,11 @@ static int cmd_show_ref__patterns(const struct patterns_options *opts,
>   	return 0;
>   }
>   > -static int cmd_show_ref__exists(const char **refs)
> +static int cmd_show_ref__raw(const char **refs, int show)
>   {
> -	struct strbuf unused_referent = STRBUF_INIT;
> -	struct object_id unused_oid;
> -	unsigned int unused_type;
> +	struct strbuf referent = STRBUF_INIT;
> +	struct object_id oid;
> +	unsigned int type;
>   	int failure_errno = 0;
>   	const char *ref;
>   	int ret = 0;
> @@ -236,7 +237,7 @@ static int cmd_show_ref__exists(const char **refs)
>   		die("--exists requires exactly one reference");
>   >   	if (refs_read_raw_ref(get_main_ref_store(the_repository), ref,
> -			      &unused_oid, &unused_referent, &unused_type,
> +			      &oid, &referent, &type,
>   			      &failure_errno)) {
>   		if (failure_errno == ENOENT || failure_errno == EISDIR) {
>   			error(_("reference does not exist"));
> @@ -250,8 +251,16 @@ static int cmd_show_ref__exists(const char **refs)
>   		goto out;
>   	}
>   > +		if (!show)
> +			goto out;
> +
> +		if (type & REF_ISSYMREF)
> +			printf("ref: %s\n", referent.buf);
> +		else
> +			printf("ref: %s\n", oid_to_hex(&oid));
> +
>   out:
> -	strbuf_release(&unused_referent);
> +	strbuf_release(&referent);
>   	return ret;
>   }
>   > @@ -284,11 +293,12 @@ int cmd_show_ref(int argc, const char **argv, const char *prefix)
>   	struct exclude_existing_options exclude_existing_opts = {0};
>   	struct patterns_options patterns_opts = {0};
>   	struct show_one_options show_one_opts = {0};
> -	int verify = 0, exists = 0;
> +	int verify = 0, exists = 0, unresolved = 0;
>   	const struct option show_ref_options[] = {
>   		OPT_BOOL(0, "tags", &patterns_opts.tags_only, N_("only show tags (can be combined with heads)")),
>   		OPT_BOOL(0, "heads", &patterns_opts.heads_only, N_("only show heads (can be combined with tags)")),
>   		OPT_BOOL(0, "exists", &exists, N_("check for reference existence without resolving")),
> +		OPT_BOOL(0, "unresolved", &unresolved, N_("print out unresolved value of reference")),
>   		OPT_BOOL(0, "verify", &verify, N_("stricter reference checking, "
>   			    "requires exact ref path")),
>   		OPT_HIDDEN_BOOL('h', NULL, &patterns_opts.show_head,
> @@ -314,16 +324,17 @@ int cmd_show_ref(int argc, const char **argv, const char *prefix)
>   	argc = parse_options(argc, argv, prefix, show_ref_options,
>   			     show_ref_usage, 0);
>   > -	die_for_incompatible_opt3(exclude_existing_opts.enabled, "--exclude-existing",
> +	die_for_incompatible_opt4(exclude_existing_opts.enabled, "--exclude-existing",
>   				  verify, "--verify",
> -				  exists, "--exists");
> +				  exists, "--exists",
> +				  unresolved, "--unresolved");
>   >   	if (exclude_existing_opts.enabled)
>   		return cmd_show_ref__exclude_existing(&exclude_existing_opts);
>   	else if (verify)
>   		return cmd_show_ref__verify(&show_one_opts, argv);
> -	else if (exists)
> -		return cmd_show_ref__exists(argv);
> +	else if (exists || unresolved)
> +		return cmd_show_ref__raw(argv, unresolved);
>   	else
>   		return cmd_show_ref__patterns(&patterns_opts, &show_one_opts, argv);
>   }
> diff --git a/t/t1403-show-ref.sh b/t/t1403-show-ref.sh
> index 33fb7a38fff..11811201738 100755
> --- a/t/t1403-show-ref.sh
> +++ b/t/t1403-show-ref.sh
> @@ -218,6 +218,16 @@ test_expect_success 'show-ref sub-modes are mutually exclusive' '
>   	test_must_fail git show-ref --exclude-existing --exists 2>err &&
>   	grep "exclude-existing" err &&
>   	grep "exists" err &&
> +	grep "cannot be used together" err &&
> +
> +	test_must_fail git show-ref --exclude-existing --unresolved 2>err &&
> +	grep "exclude-existing" err &&
> +	grep "unresolved" err &&
> +	grep "cannot be used together" err &&
> +
> +	test_must_fail git show-ref --verify --unresolved 2>err &&
> +	grep "verify" err &&
> +	grep "unresolved" err &&
>   	grep "cannot be used together" err
>   '
>   > @@ -286,4 +296,41 @@ test_expect_success '--exists with existing special ref' '
>   	git show-ref --exists FETCH_HEAD
>   '
>   > +test_expect_success '--unresolved with existing reference' '
> +	commit_oid=$(git rev-parse refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME) &&
> +	cat >expect <<-EOF &&
> +	ref: $commit_oid
> +	EOF
> +	git show-ref --unresolved refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME >actual &&
> +	test_cmp expect actual
> +'
> +
> +test_expect_success '--unresolved with symbolic ref' '
> +	test_when_finished "git symbolic-ref -d SYMBOLIC_REF_A" &&
> +	cat >expect <<-EOF &&
> +	ref: refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
> +	EOF
> +	git symbolic-ref SYMBOLIC_REF_A refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME &&
> +	git show-ref --unresolved SYMBOLIC_REF_A >actual &&
> +	test_cmp expect actual
> +'
> +
> +test_expect_success '--unresolved with nonexistent object ID' '
> +	oid=$(test_oid 002) &&
> +	test-tool ref-store main update-ref msg refs/heads/missing-oid-2 $oid $ZERO_OID REF_SKIP_OID_VERIFICATION &&
> +	cat >expect <<-EOF &&
> +	ref: $oid
> +	EOF
> +	git show-ref --unresolved refs/heads/missing-oid-2 >actual &&
> +	test_cmp expect actual
> +'
> +
> +test_expect_success '--unresolved with nonexistent reference' '
> +	cat >expect <<-EOF &&
> +	error: reference does not exist
> +	EOF
> +	test_expect_code 2 git show-ref --unresolved refs/heads/not-exist 2>err &&
> +	test_cmp expect err
> +'
> +
>   test_done
> > base-commit: b387623c12f3f4a376e4d35a610fd3e55d7ea907

Copy link

User Phillip Wood <[email protected]> has been added to the cc: list.

Copy link

On the Git mailing list, "Kristoffer Haugsbakk" wrote (reply to this):

On Tue, Mar 5, 2024, at 16:30, Phillip Wood wrote:
> Hi John
>
> On 04/03/2024 22:51, John Cai via GitGitGadget wrote:
>> From: John Cai <[email protected]>
>>
>> For reftable development, it would be handy to have a tool to provide
>> the direct value of any ref whether it be a symbolic ref or not.
>> Currently there is git-symbolic-ref, which only works for symbolic refs,
>> and git-rev-parse, which will resolve the ref. Let's add a --unresolved
>> option that will only take one ref and return whatever it points to
>> without dereferencing it.
>
> "--unresolved" makes me think of merge conflicts. I wonder if
> "--no-dereference" would be clearer.

Yeah, a `--no`-style option looks more consistent.

Copy link

User "Kristoffer Haugsbakk" <[email protected]> has been added to the cc: list.

Copy link

On the Git mailing list, John Cai wrote (reply to this):

Hi Junio,

On 4 Mar 2024, at 18:23, Junio C Hamano wrote:

> "John Cai via GitGitGadget" <[email protected]> writes:
>
>> From: John Cai <[email protected]>
>>
>> For reftable development, it would be handy to have a tool to provide
>> the direct value of any ref whether it be a symbolic ref or not.
>> Currently there is git-symbolic-ref, which only works for symbolic refs,
>> and git-rev-parse, which will resolve the ref. Let's add a --unresolved
>> option that will only take one ref and return whatever it points to
>> without dereferencing it.
>
> The approach may be reasonble, but the above description can use
> some improvements.
>
>  * Even though the title of the patch says show-ref, the last
>    sentence is a bit too far from there and it was unclear to what
>    you are adding a new feature at least to me during my first read.
>
>       Let's teach show-ref a `--unresolved` optionthat will ...
>
>    may make it easier to follow.
>
>  * "Whatever it points to without dereferencing it" implied that it
>    assumes what it is asked to show can be dereferenced, which
>    invites a natural question: what happens to a thing that is not
>    dereferenceable in the first place?  The implementation seems to
>    show either symbolic-ref target (for symbolic refs) or the object
>    name (for others), but let's make it easier for readers.

Yeah good point. The language could be made more precise.

>
>>  Documentation/git-show-ref.txt |  8 ++++++
>>  builtin/show-ref.c             | 33 ++++++++++++++++--------
>>  t/t1403-show-ref.sh            | 47 ++++++++++++++++++++++++++++++++++
>>  3 files changed, 77 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
>> index ba757470059..2f9b4de1346 100644
>> --- a/Documentation/git-show-ref.txt
>> +++ b/Documentation/git-show-ref.txt
>> @@ -16,6 +16,7 @@ SYNOPSIS
>>  	     [--] [<ref>...]
>>  'git show-ref' --exclude-existing[=<pattern>]
>>  'git show-ref' --exists <ref>
>> +'git show-ref' --unresolved <ref>
>>
>>  DESCRIPTION
>>  -----------
>> @@ -76,6 +77,13 @@ OPTIONS
>>  	it does, 2 if it is missing, and 1 in case looking up the reference
>>  	failed with an error other than the reference being missing.
>>
>> +--unresolved::
>> +
>> +	Prints out what the reference points to without resolving it. Returns
>> +	an exit code of 0 if it does, 2 if it is missing, and 1 in case looking
>> +	up the reference failed with an error other than the reference being
>> +	missing.
>
> Exactly the same issue as in the proposed log message, i.e. what is
> printed for what kind of ref is not really clear.
>
>> -static int cmd_show_ref__exists(const char **refs)
>> +static int cmd_show_ref__raw(const char **refs, int show)
>>  {
>> -	struct strbuf unused_referent = STRBUF_INIT;
>> -	struct object_id unused_oid;
>> -	unsigned int unused_type;
>> +	struct strbuf referent = STRBUF_INIT;
>> +	struct object_id oid;
>> +	unsigned int type;
>>  	int failure_errno = 0;
>>  	const char *ref;
>>  	int ret = 0;
>> @@ -236,7 +237,7 @@ static int cmd_show_ref__exists(const char **refs)
>>  		die("--exists requires exactly one reference");
>>
>>  	if (refs_read_raw_ref(get_main_ref_store(the_repository), ref,
>> -			      &unused_oid, &unused_referent, &unused_type,
>> +			      &oid, &referent, &type,
>>  			      &failure_errno)) {
>>  		if (failure_errno == ENOENT || failure_errno == EISDIR) {
>>  			error(_("reference does not exist"));
>> @@ -250,8 +251,16 @@ static int cmd_show_ref__exists(const char **refs)
>>  		goto out;
>>  	}
>>
>> +		if (!show)
>> +			goto out;
>> +
>> +		if (type & REF_ISSYMREF)
>> +			printf("ref: %s\n", referent.buf);
>> +		else
>> +			printf("ref: %s\n", oid_to_hex(&oid));
>
> If I create a symbolic ref whose value is deadbeef....deadbeef 40-hex,
> I cannot tell from this output if it is a symbolic ref of a ref that
> stores an object whose name is that hash.  Reserve the use of "ref: %s"
> to the symbolic refs (so that it will also match how the files backend
> stores them in modern Git), and use some other prefix (or no
> perfix).
>
> Actually, I am not sure if what is proposed is even a good
> interface.  Given a repository with these few refs:
>
>     $ git show-ref refs/heads/master
>     b387623c12f3f4a376e4d35a610fd3e55d7ea907 refs/heads/master
>     $ git show-ref refs/remotes/repo/HEAD
>     b387623c12f3f4a376e4d35a610fd3e55d7ea907 refs/remotes/repo/HEAD
>     $ git symbolic-ref refs/remotes/repo/HEAD
>     refs/remotes/repo/master
>
> I would think that the second command above shows the gap in feature
> set our current "show-ref" has.  If we could do
>
>     $ git show-ref --<option> refs/heads/master refs/remotes/repo/HEAD
>     b387623c12f3f4a376e4d35a610fd3e55d7ea907 refs/heads/master
>     ref:refs/remotes/repo/master refs/remotes/repo/HEAD

I like this option. It makes it clear that it's a symbolic ref without adding
additional output to the command.

cc'ing Patrick here for his thoughts as well since he has interest in this topic.

>
> or alternatively
>
>     $ git show-ref --<option> refs/heads/master refs/remotes/repo/HEAD
>     b387623c12f3f4a376e4d35a610fd3e55d7ea907 refs/heads/master
>     ref:refs/remotes/repo/master b387623c12f3f4a376e4d35a610fd3e55d7ea907 refs/remotes/repo/HEAD
>
> wouldn't it match the existing feature set better?  You also do not
> have to limit yourself to single ref query per process invocation.
>
> I am not sure if you need to worry about quoting of the values of
> symbolic-ref, though.  You _might_ need to move the (optional)
> symref information to the end, i.e. something like this you might
> prefer.  I dunno.
>
>     $ git show-ref --<option> refs/remotes/repo/HEAD
>     b387623c12f3f4a376e4d35a610fd3e55d7ea907 refs/remotes/repo/HEAD refs/remotes/repo/master
>
> I do not know what the <option> should be called, either.  From an
> end-user's point of view, the option tells the command to also
> report which ref the ref points at, if it were a symbolic one.
> "unresolved" may be technically acceptable name to those who know
> the underlying implementation (i.e. we tell read_raw_ref not to
> resolve when it does its thing), but I am afraid that is a bit too
> opaque implementation detail for end-users who are expected to learn
> this option.

I think something like --no-dereference that was suggested in [1] could work
since the concept of dereferencing should be familiar to the user. However, this
maybe confusing because of the existing --dereference flag that is specific to
tags...

1. https://lore.kernel.org/git/[email protected]/

thanks
John

Copy link

On the Git mailing list, Junio C Hamano wrote (reply to this):

John Cai <[email protected]> writes:

> I think something like --no-dereference that was suggested in [1] could work
> since the concept of dereferencing should be familiar to the user. However, this
> maybe confusing because of the existing --dereference flag that is specific to
> tags...

True.

As a symbolic reference is like a symbolic link [*], another possibility
is to use "follow", which often is used to refer to the action of
reading the contents of a symbolic link and using it as the target
pathname (e.g., O_NOFOLLOW flag forbids open(2) from following
symbolic links).  Unfortunately the checkbox feature "--follow" the
"git log" has refers to an entirely different kind of following, so
it is just as confusing as --dereference.

Perhaps "--readlink", if you are showing only "ref: refs/heads/main"
instead of the usual object name in the output?  If we are showing
both, we may want to use a name that signals the optional nature of
the symref part of the output, e.g., "--with-symref-target" [*].


[Footnote]

 * In fact that is how the symbolic reference started out as.  We
   literally used a symbolic link .git/HEAD that points at the
   current branch, which can be seen in v0.99~418 (git-init-db: set
   up the full default environment, 2005-05-30).

 * Yes, I know, I am terrible at naming things---my names may be
   descriptive but end up being unusably long and verbose.

Copy link

On the Git mailing list, Jeff King wrote (reply to this):

On Tue, Mar 05, 2024 at 03:30:35PM +0000, Phillip Wood wrote:

> Hi John
> 
> On 04/03/2024 22:51, John Cai via GitGitGadget wrote:
> > From: John Cai <[email protected]>
> > 
> > For reftable development, it would be handy to have a tool to provide
> > the direct value of any ref whether it be a symbolic ref or not.
> > Currently there is git-symbolic-ref, which only works for symbolic refs,
> > and git-rev-parse, which will resolve the ref. Let's add a --unresolved
> > option that will only take one ref and return whatever it points to
> > without dereferencing it.
> 
> "--unresolved" makes me think of merge conflicts. I wonder if
> "--no-dereference" would be clearer.

We have "--no-deref" in "git update-ref" already. It is probably better
to stay consistent.

-Peff

Copy link

User Jeff King <[email protected]> has been added to the cc: list.

Copy link

On the Git mailing list, Jeff King wrote (reply to this):

On Mon, Mar 04, 2024 at 10:51:58PM +0000, John Cai via GitGitGadget wrote:

> From: John Cai <[email protected]>
> 
> For reftable development, it would be handy to have a tool to provide
> the direct value of any ref whether it be a symbolic ref or not.
> Currently there is git-symbolic-ref, which only works for symbolic refs,
> and git-rev-parse, which will resolve the ref. Let's add a --unresolved
> option that will only take one ref and return whatever it points to
> without dereferencing it.

What about "git rev-parse --symbolic-full-name"? I don't think that
behaves quite the same as your patch here:

  - it is actually not a true no-deref; it resolves to the final name
    and then prints it (so the behavior is the same for a single-level
    symref, but I believe a multi-level symref chain like
    one->two->three will print "three" when resolving "one").

  - it always prints the resolved name, whereas your patch prints an oid
    for non-symrefs

I'm not sure if those are important or not, as I don't quite understand
what you're trying to accomplish. I'd probably have just run:

  git symbolic-ref -q $name || git rev-parse --verify $name

I'm not opposed to making that more ergonomic, but I think we should
avoid redundant plumbing options if we can (I'm not sure yet if this is
redundant or not, but in general I find "show-ref" to be a weird mix of
"rev-parse" and "for-each-ref" that I'd be just as happy if it did not
exist).

-Peff

Copy link

On the Git mailing list, Junio C Hamano wrote (reply to this):

Jeff King <[email protected]> writes:

> On Tue, Mar 05, 2024 at 03:30:35PM +0000, Phillip Wood wrote:
>
>> Hi John
>> 
>> On 04/03/2024 22:51, John Cai via GitGitGadget wrote:
>> > From: John Cai <[email protected]>
>> > 
>> > For reftable development, it would be handy to have a tool to provide
>> > the direct value of any ref whether it be a symbolic ref or not.
>> > Currently there is git-symbolic-ref, which only works for symbolic refs,
>> > and git-rev-parse, which will resolve the ref. Let's add a --unresolved
>> > option that will only take one ref and return whatever it points to
>> > without dereferencing it.
>> 
>> "--unresolved" makes me think of merge conflicts. I wonder if
>> "--no-dereference" would be clearer.
>
> We have "--no-deref" in "git update-ref" already. It is probably better
> to stay consistent.

That's an excellent precedent.  Thanks.

Copy link

On the Git mailing list, Patrick Steinhardt wrote (reply to this):

On Tue, Mar 05, 2024 at 07:41:39PM -0500, Jeff King wrote:
> On Mon, Mar 04, 2024 at 10:51:58PM +0000, John Cai via GitGitGadget wrote:
> 
> > From: John Cai <[email protected]>
> > 
> > For reftable development, it would be handy to have a tool to provide
> > the direct value of any ref whether it be a symbolic ref or not.
> > Currently there is git-symbolic-ref, which only works for symbolic refs,
> > and git-rev-parse, which will resolve the ref. Let's add a --unresolved
> > option that will only take one ref and return whatever it points to
> > without dereferencing it.
> 
> What about "git rev-parse --symbolic-full-name"? I don't think that
> behaves quite the same as your patch here:
> 
>   - it is actually not a true no-deref; it resolves to the final name
>     and then prints it (so the behavior is the same for a single-level
>     symref, but I believe a multi-level symref chain like
>     one->two->three will print "three" when resolving "one").
> 
>   - it always prints the resolved name, whereas your patch prints an oid
>     for non-symrefs
> 
> I'm not sure if those are important or not, as I don't quite understand
> what you're trying to accomplish. I'd probably have just run:
> 
>   git symbolic-ref -q $name || git rev-parse --verify $name
> 
> I'm not opposed to making that more ergonomic, but I think we should
> avoid redundant plumbing options if we can (I'm not sure yet if this is
> redundant or not, but in general I find "show-ref" to be a weird mix of
> "rev-parse" and "for-each-ref" that I'd be just as happy if it did not
> exist).

Yeah, the proposed patch basically aims to do the above chained command
in an easier way. I think that this would be a nice addition to make
this easier to use and better discoverable. But in the long run what I
think would be really useful is to extend git-for-each-ref(1) and/or
git-show-ref(1) so that they can print all existing refs with their
direct values. Right now, it's impossible to get a globally consistent
view of all refs in the refdb with their unresolved values.

That will end up a bit more involved though. The ref iterators we have
right now do not provide any way to return symref targets to the caller,
so we would have to first extend the interfaces and adapt both backends
to support this. But this is kind of where I want to end up.

Patrick

Copy link

User Patrick Steinhardt <[email protected]> has been added to the cc: list.

Copy link

On the Git mailing list, Jeff King wrote (reply to this):

On Wed, Mar 06, 2024 at 08:31:15AM +0100, Patrick Steinhardt wrote:

> Yeah, the proposed patch basically aims to do the above chained command
> in an easier way. I think that this would be a nice addition to make
> this easier to use and better discoverable. But in the long run what I
> think would be really useful is to extend git-for-each-ref(1) and/or
> git-show-ref(1) so that they can print all existing refs with their
> direct values. Right now, it's impossible to get a globally consistent
> view of all refs in the refdb with their unresolved values.

Yeah, it seems like if this were a format-specifier for for-each-ref it
would be a lot more flexible.

You can do:

  git for-each-ref --format='%(refname) %(objectname) %(symref)'

to get the resolved values next to the symrefs (if any). I think that
does a full resolution, though (so again, if you had one->two->three,
you can never learn about the intermediate "two").

> That will end up a bit more involved though. The ref iterators we have
> right now do not provide any way to return symref targets to the caller,
> so we would have to first extend the interfaces and adapt both backends
> to support this. But this is kind of where I want to end up.

I think for-each-ref in the above command works by calling
resolve_refdup() itself, and then recording the result. It would be nice
to get it from the iterator, though (more efficient, and avoids any
races).

-Peff

Copy link

On the Git mailing list, Jean-Noël Avila wrote (reply to this):

Le 04/03/2024 à 23:51, John Cai via GitGitGadget a écrit :
> From: John Cai <[email protected]>
> > @@ -76,6 +77,13 @@ OPTIONS
>  	it does, 2 if it is missing, and 1 in case looking up the reference
>  	failed with an error other than the reference being missing.
>  
> +--unresolved::
> +
> +	Prints out what the reference points to without resolving it. Returns

Style nitpicking: we use imperative form in the descriptions of options
→ Print out what... Return...

> +	an exit code of 0 if it does, 2 if it is missing, and 1 in case looking
> +	up the reference failed with an error other than the reference being
> +	missing.
> +
>  --abbrev[=<n>]::
>  
>  	Abbreviate the object name.  When using `--hash`, you do

Copy link

User Jean-Noël Avila <[email protected]> has been added to the cc: list.

Copy link

On the Git mailing list, Junio C Hamano wrote (reply to this):

Jeff King <[email protected]> writes:

> You can do:
>
>   git for-each-ref --format='%(refname) %(objectname) %(symref)'

We can even do that "ref target || object name" thing with

--format='%(refname) %(if)%(symref)%(then)%(symref)%(else)%(objectname)'

if we wanted to.  But if we have both available, I think the output
that adds the symref target, if available, after the object name, is
better than the output that switches between the two.

> to get the resolved values next to the symrefs (if any). I think that
> does a full resolution, though (so again, if you had one->two->three,
> you can never learn about the intermediate "two").

Yeah, I know we discussed the usefulness of tag-of-tag-of-something,
but this is a similar one.  

> I think for-each-ref in the above command works by calling
> resolve_refdup() itself, and then recording the result. It would be nice
> to get it from the iterator, though (more efficient, and avoids any
> races).

Indeed.  Thanks for an interesting thought.

Copy link

There are issues in commit 72ad036:
refs: pass down referent in the case of a symbolic ref
Commit checks stopped - the message is too short
Commit not signed off

Copy link

There are issues in commit fb6141e:
show-ref: add --no-dereference option
Commit not signed off

@john-cai john-cai force-pushed the jc/show-ref-direct branch 2 times, most recently from 95b1839 to 89c5123 Compare April 4, 2024 20:36
@john-cai john-cai changed the title show-ref: add --unresolved option show-ref: add --symbolic-name option Apr 4, 2024
Copy link

There are issues in commit 1cac748:
show-ref: add --symbolic-name option
Commit not signed off

@john-cai john-cai force-pushed the jc/show-ref-direct branch 5 times, most recently from 4f46c05 to 08c9834 Compare April 8, 2024 15:27
Since ref iterators do not hold onto the direct value of a reference
without resolving it, the only way to get ahold of a direct value of a
symbolic ref is to make a separate call to refs_read_symbolic_ref.

To make accessing the direct value of a symbolic ref more efficient,
let's save the direct value of the ref in the iterator for both the
files backend and reftable backend.

To do so, we also need to add an argument to refs_resolve_ref_unsafe to
save the direct value of the reference somewhere.

Signed-off-by: John Cai <[email protected]>
There is no way for callers of the refs api functions that use iterators
to get a hold of a direct value of a symbolic ref before its resolved in
the callback functions, as either each_ref_fn nor each_repo_ref_fn have
an argument for this.

This did not matter since the iterators did not hold onto the direct
value of a reference anyway. But, the previous commit started to save
the value of the direct reference in the iterator.

Add an argument to each_repo_ref_fn that gets passed the direct
value of a reference.

Signed-off-by: John Cai <[email protected]>
For reftable development, it would be handy to have a tool to provide
the direct value of any ref whether it be a symbolic ref or not.
Currently there is git-symbolic-ref, which only works for symbolic refs,
and git-rev-parse, which will resolve the ref. Let's teach show-ref a
--symbolic-name option that will cause git-show-ref(1) to print out the
value symbolic references points to.

Signed-off-by: John Cai <[email protected]>
@john-cai
Copy link
Contributor Author

john-cai commented Apr 8, 2024

/preview

Copy link

Preview email sent as [email protected]

@john-cai
Copy link
Contributor Author

john-cai commented Apr 8, 2024

/submit

Copy link

Submitted as [email protected]

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-git-1684/john-cai/jc/show-ref-direct-v2

To fetch this version to local tag pr-git-1684/john-cai/jc/show-ref-direct-v2:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-git-1684/john-cai/jc/show-ref-direct-v2

@@ -45,7 +45,7 @@ static int repo_get_default_remote(struct repository *repo, char **default_remot
char *dest = NULL;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Junio C Hamano wrote (reply to this):

> diff --git a/refs.h b/refs.h
> index 298caf6c618..2e740c692ac 100644
> --- a/refs.h
> +++ b/refs.h
> @@ -71,9 +71,10 @@ struct pack_refs_opts {
>  	struct ref_exclusions *exclusions;
>  	struct string_list *includes;
>  };
> -
>  const char *refs_resolve_ref_unsafe(struct ref_store *refs,
> +
>  				    const char *refname,
> +				    char **referent,
>  				    int resolve_flags,
>  				    struct object_id *oid,
>  				    int *flags);

If referent is meant to be an out-parameter, it should sit next to
oid that is also an out-parameter.  And as a late-comer sibling, it
should sit after its elder brother.

Also, I do not see the reason for the shuffling of blank lines.
Shouldn't it be the other way around, even?  After an unrelated
definition of "struct pack_refs_opts", there is (and should be)
a blank line, then the first line of the declaration of function.

Perhaps some fat-fingering.

> @@ -1928,6 +1928,7 @@ int refs_read_symbolic_ref(struct ref_store *ref_store, const char *refname,
>  
>  const char *refs_resolve_ref_unsafe(struct ref_store *refs,
>  				    const char *refname,
> +				    char **referent,
>  				    int resolve_flags,
>  				    struct object_id *oid,
>  				    int *flags)
> @@ -1989,6 +1990,8 @@ const char *refs_resolve_ref_unsafe(struct ref_store *refs,
>  		}
>  
>  		*flags |= read_flags;
> +		if (referent && read_flags & REF_ISSYMREF && sb_refname.len > 0)
> +			*referent = sb_refname.buf;

Is this safe?  After this assignment, which "return" in this loop
are you expecting to return from this function?  If you fail to
return from the function during this iteration, you'll clobber the
same strbuf with the next refs_read_raw_ref(), but I do not see how
you are ensuring that you'll return from the function without such
corruption happening.

This assignment happens only when read_flags has REF_ISSYMREF set,
so the next "if it is not, then return refname" would not even
trigger.  If RESOLVE_REF_NO_RECURSE bit is on in resolve_flags,
then we'd return without further dereferencing, but if that is the
only safe exit from the function, shouldn't you be guarding the
function with something like

	if (referent && !(resolve_flags & RESOLVE_REF_NO_RECURSE))
		BUG("recursive dereference can will clobber *referent");

to protect its callers from their own mistakes?

Another return before we start the next iteration of the loop and
clobber sb_refname with another call to refs_read_raw_ref() is the
error return codepath at the end of the loop, but that is a totally
uninteresting case.

Or am I totally confused?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, John Cai wrote (reply to this):

Hi Junio

On 8 Apr 2024, at 19:02, Junio C Hamano wrote:

>> diff --git a/refs.h b/refs.h
>> index 298caf6c618..2e740c692ac 100644
>> --- a/refs.h
>> +++ b/refs.h
>> @@ -71,9 +71,10 @@ struct pack_refs_opts {
>>  	struct ref_exclusions *exclusions;
>>  	struct string_list *includes;
>>  };
>> -
>>  const char *refs_resolve_ref_unsafe(struct ref_store *refs,
>> +
>>  				    const char *refname,
>> +				    char **referent,
>>  				    int resolve_flags,
>>  				    struct object_id *oid,
>>  				    int *flags);
>
> If referent is meant to be an out-parameter, it should sit next to
> oid that is also an out-parameter.  And as a late-comer sibling, it
> should sit after its elder brother.
>
> Also, I do not see the reason for the shuffling of blank lines.
> Shouldn't it be the other way around, even?  After an unrelated
> definition of "struct pack_refs_opts", there is (and should be)
> a blank line, then the first line of the declaration of function.
>
> Perhaps some fat-fingering.

This was indeed a case of fat-fingering.

>
>> @@ -1928,6 +1928,7 @@ int refs_read_symbolic_ref(struct ref_store *ref_store, const char *refname,
>>
>>  const char *refs_resolve_ref_unsafe(struct ref_store *refs,
>>  				    const char *refname,
>> +				    char **referent,
>>  				    int resolve_flags,
>>  				    struct object_id *oid,
>>  				    int *flags)
>> @@ -1989,6 +1990,8 @@ const char *refs_resolve_ref_unsafe(struct ref_store *refs,
>>  		}
>>
>>  		*flags |= read_flags;
>> +		if (referent && read_flags & REF_ISSYMREF && sb_refname.len > 0)
>> +			*referent = sb_refname.buf;
>
> Is this safe?  After this assignment, which "return" in this loop
> are you expecting to return from this function?  If you fail to
> return from the function during this iteration, you'll clobber the
> same strbuf with the next refs_read_raw_ref(), but I do not see how
> you are ensuring that you'll return from the function without such
> corruption happening.
>
> This assignment happens only when read_flags has REF_ISSYMREF set,
> so the next "if it is not, then return refname" would not even
> trigger.  If RESOLVE_REF_NO_RECURSE bit is on in resolve_flags,
> then we'd return without further dereferencing, but if that is the
> only safe exit from the function, shouldn't you be guarding the
> function with something like
>
> 	if (referent && !(resolve_flags & RESOLVE_REF_NO_RECURSE))
> 		BUG("recursive dereference can will clobber *referent");
>
> to protect its callers from their own mistakes?
>
> Another return before we start the next iteration of the loop and
> clobber sb_refname with another call to refs_read_raw_ref() is the
> error return codepath at the end of the loop, but that is a totally
> uninteresting case.
>
> Or am I totally confused?

Yeah good point. This probably not a good idea. In fact, perhaps adding another
argument to this function is unnecessary. We already have refs_read_symbolic_ref
and we can just make a separate call to that once we know that a ref is a
symbolic reference. Though a separate call is less efficient, I'm not sure it's
worth adding this parameter.

thanks
John

@@ -10,7 +10,7 @@ SYNOPSIS
[verse]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Phillip Wood wrote (reply to this):

Hi John

On 08/04/2024 18:38, John Cai via GitGitGadget wrote:
> +--symbolic-name::
> +
> +	Print out the value the reference points to without dereferencing. This
> +	is useful to know the reference that a symbolic ref is pointing to.

It would be helpful to clarify that this prints the contents of the symbolic ref without dereferencing but also prints the OID after dereferencing the given ref.

> +When using `--symbolic-name`, the output is in the format:
> +
> +-----------
> +<oid> SP <ref> SP <symbolic-name>
> +-----------
> +
> +For example,
> +
> +-----------------------------------------------------------------------------
> +$ git show-ref --symbolic-name
> +b75428bae1d090f60bdd4b67185f814bc8f0819d refs/heads/SYMBOLIC_REF ref:refs/heads/main

Do we really need the "ref:" prefix? It is not specified above and I think anyone calling this would have to remove the prefix before they could use the value.


> +test_expect_success '--symbolic-name with symbolic ref' '
> +	test_when_finished "git symbolic-ref -d refs/heads/SYMBOLIC_REF_A" &&
> +	commit_oid=$(git rev-parse refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME) &&
> +	cat >expect <<-EOF &&
> +	$commit_oid refs/heads/SYMBOLIC_REF_A ref:refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
> +	EOF
> +	git symbolic-ref refs/heads/SYMBOLIC_REF_A refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME &&
> +	git show-ref --symbolic-name SYMBOLIC_REF_A >actual &&
> +	test_cmp expect actual
> +'

I think it would be nice to see a test along the lines of

	git symbolic-ref refs/symref-c refs/heads/master
	git symbolic-ref refs/symref-b refs/symref-c &&
	git symbolic-ref refs/symref-a refs/symref-b &&
	git show-ref --symbolic-name refs/symref-a >actual &&
	cat >expect <<\EOF &&
	$(git show-ref -s --verify refs/heads/master) refs/heads/symref-a refs/heads/symref-b
	EOF
	test_cmp expect actual

to show what this command is expected to return when there is a chain of symbolic references.

Best Wishes

Phillip

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, John Cai wrote (reply to this):

Hi Phillip,

On 9 Apr 2024, at 11:25, Phillip Wood wrote:

> Hi John
>
> On 08/04/2024 18:38, John Cai via GitGitGadget wrote:
>> +--symbolic-name::
>> +
>> +	Print out the value the reference points to without dereferencing. This
>> +	is useful to know the reference that a symbolic ref is pointing to.
>
> It would be helpful to clarify that this prints the contents of the symbolic ref without dereferencing but also prints the OID after dereferencing the given ref.

Thanks, will clarify in the next version.

>
>> +When using `--symbolic-name`, the output is in the format:
>> +
>> +-----------
>> +<oid> SP <ref> SP <symbolic-name>
>> +-----------
>> +
>> +For example,
>> +
>> +-----------------------------------------------------------------------------
>> +$ git show-ref --symbolic-name
>> +b75428bae1d090f60bdd4b67185f814bc8f0819d refs/heads/SYMBOLIC_REF ref:refs/heads/main
>
> Do we really need the "ref:" prefix? It is not specified above and I think anyone calling this would have to remove the prefix before they could use the value.

I can see how it would be more ergonimic to just have the value without the
"ref: " prefix. I kept it because that's how the refs are represented on disk
and git-symbolic-ref prints them out with the "ref: " prefix.

I don't have a strong preference, but I lean a bit towards keeping it consistent
with the output of other commands.

>
>
>> +test_expect_success '--symbolic-name with symbolic ref' '
>> +	test_when_finished "git symbolic-ref -d refs/heads/SYMBOLIC_REF_A" &&
>> +	commit_oid=$(git rev-parse refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME) &&
>> +	cat >expect <<-EOF &&
>> +	$commit_oid refs/heads/SYMBOLIC_REF_A ref:refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
>> +	EOF
>> +	git symbolic-ref refs/heads/SYMBOLIC_REF_A refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME &&
>> +	git show-ref --symbolic-name SYMBOLIC_REF_A >actual &&
>> +	test_cmp expect actual
>> +'
>
> I think it would be nice to see a test along the lines of
>
> 	git symbolic-ref refs/symref-c refs/heads/master
> 	git symbolic-ref refs/symref-b refs/symref-c &&
> 	git symbolic-ref refs/symref-a refs/symref-b &&
> 	git show-ref --symbolic-name refs/symref-a >actual &&
> 	cat >expect <<\EOF &&
> 	$(git show-ref -s --verify refs/heads/master) refs/heads/symref-a refs/heads/symref-b
> 	EOF
> 	test_cmp expect actual
>
> to show what this command is expected to return when there is a chain of symbolic references.

good point, will add this in the next series.

>
> Best Wishes
>
> Phillip

thanks for the review!
John

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, [email protected] wrote (reply to this):

Hi John

On 11/04/2024 20:57, John Cai wrote:
> On 9 Apr 2024, at 11:25, Phillip Wood wrote:
>>> +When using `--symbolic-name`, the output is in the format:
>>> +
>>> +-----------
>>> +<oid> SP <ref> SP <symbolic-name>
>>> +-----------
>>> +
>>> +For example,
>>> +
>>> +-----------------------------------------------------------------------------
>>> +$ git show-ref --symbolic-name
>>> +b75428bae1d090f60bdd4b67185f814bc8f0819d refs/heads/SYMBOLIC_REF ref:refs/heads/main
>>
>> Do we really need the "ref:" prefix? It is not specified above and I think anyone calling this would have to remove the prefix before they could use the value.
> > I can see how it would be more ergonimic to just have the value without the
> "ref: " prefix. I kept it because that's how the refs are represented on disk
> and git-symbolic-ref prints them out with the "ref: " prefix.
> > I don't have a strong preference, but I lean a bit towards keeping it consistent
> with the output of other commands.

I agree it is a good idea to keep things consistent, and dropping the "ref:" prefix is consistent with other commands:

$ git symbolic-ref HEAD
refs/heads/rebase-fix-signoff

Best Wishes

Phillip

> >>
>>
>>> +test_expect_success '--symbolic-name with symbolic ref' '
>>> +	test_when_finished "git symbolic-ref -d refs/heads/SYMBOLIC_REF_A" &&
>>> +	commit_oid=$(git rev-parse refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME) &&
>>> +	cat >expect <<-EOF &&
>>> +	$commit_oid refs/heads/SYMBOLIC_REF_A ref:refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
>>> +	EOF
>>> +	git symbolic-ref refs/heads/SYMBOLIC_REF_A refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME &&
>>> +	git show-ref --symbolic-name SYMBOLIC_REF_A >actual &&
>>> +	test_cmp expect actual
>>> +'
>>
>> I think it would be nice to see a test along the lines of
>>
>> 	git symbolic-ref refs/symref-c refs/heads/master
>> 	git symbolic-ref refs/symref-b refs/symref-c &&
>> 	git symbolic-ref refs/symref-a refs/symref-b &&
>> 	git show-ref --symbolic-name refs/symref-a >actual &&
>> 	cat >expect <<\EOF &&
>> 	$(git show-ref -s --verify refs/heads/master) refs/heads/symref-a refs/heads/symref-b
>> 	EOF
>> 	test_cmp expect actual
>>
>> to show what this command is expected to return when there is a chain of symbolic references.
> > good point, will add this in the next series.
> >>
>> Best Wishes
>>
>> Phillip
> > thanks for the review!
> John

@@ -45,7 +45,7 @@ static int repo_get_default_remote(struct repository *repo, char **default_remot
char *dest = NULL;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Patrick Steinhardt wrote (reply to this):

On Mon, Apr 08, 2024 at 05:38:11PM +0000, John Cai via GitGitGadget wrote:
> From: John Cai <[email protected]>
[snip]
> @@ -1928,6 +1928,7 @@ int refs_read_symbolic_ref(struct ref_store *ref_store, const char *refname,
>  
>  const char *refs_resolve_ref_unsafe(struct ref_store *refs,
>  				    const char *refname,
> +				    char **referent,
>  				    int resolve_flags,
>  				    struct object_id *oid,
>  				    int *flags)

I wonder whether this really should be a `char **`. You don't seem to be
free'ing returned pointers anywhere, so this should probably at least be
`const char **` to indicate that memory is owned by the ref store. But
that would require the ref store to inevitably release it, which may
easily lead to bugs when the caller expects a different lifetime.

So how about we instead make this a `struct strbuf *referent`? This
makes it quite clear who owns the memory. Furthermore, if the caller
wants to resolve multiple refs, it would allow them to reuse the buffer
for better-optimized allocation patterns.

[snip]
> diff --git a/refs/ref-cache.c b/refs/ref-cache.c
> index 9f9797209a4..4c23b92414a 100644
> --- a/refs/ref-cache.c
> +++ b/refs/ref-cache.c
> @@ -34,12 +34,14 @@ struct ref_dir *get_ref_dir(struct ref_entry *entry)
>  }
>  
>  struct ref_entry *create_ref_entry(const char *refname,
> +				   const char *referent,
>  				   const struct object_id *oid, int flag)
>  {
>  	struct ref_entry *ref;
>  
>  	FLEX_ALLOC_STR(ref, name, refname);
>  	oidcpy(&ref->u.value.oid, oid);
> +	ref->u.value.referent = referent;
>  	ref->flag = flag;
>  	return ref;
>  }

It's kind of hard to spot the actual changes inbetween all those changes
to callsites. Is it possible to split the patch up such that we have one
patch that changes all the callsites and one patch that does the actual
changes to implement this?

Patrick

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Junio C Hamano wrote (reply to this):

Patrick Steinhardt <[email protected]> writes:

>>  const char *refs_resolve_ref_unsafe(struct ref_store *refs,
>>  				    const char *refname,
>> +				    char **referent,
>>  				    int resolve_flags,
>>  				    struct object_id *oid,
>>  				    int *flags)
>
> I wonder whether this really should be a `char **`. You don't seem to be
> free'ing returned pointers anywhere, so this should probably at least be
> `const char **` to indicate that memory is owned by the ref store. But
> that would require the ref store to inevitably release it, which may
> easily lead to bugs when the caller expects a different lifetime.
>
> So how about we instead make this a `struct strbuf *referent`? This
> makes it quite clear who owns the memory. Furthermore, if the caller
> wants to resolve multiple refs, it would allow them to reuse the buffer
> for better-optimized allocation patterns.

Or return an allocated piece of memory via "char **".  I think an
interface that _requires_ the caller to use strbuf is not nice, if
the caller is not expected to further _edit_ the returned contents
using the strbuf API.  If it is likely that the caller would want to
perform further post-processing on the result, an interface based on
strbuf is nice, but I do not think it applies to this case.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Patrick Steinhardt wrote (reply to this):

On Wed, Apr 10, 2024 at 08:26:13AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <[email protected]> writes:
> 
> >>  const char *refs_resolve_ref_unsafe(struct ref_store *refs,
> >>  				    const char *refname,
> >> +				    char **referent,
> >>  				    int resolve_flags,
> >>  				    struct object_id *oid,
> >>  				    int *flags)
> >
> > I wonder whether this really should be a `char **`. You don't seem to be
> > free'ing returned pointers anywhere, so this should probably at least be
> > `const char **` to indicate that memory is owned by the ref store. But
> > that would require the ref store to inevitably release it, which may
> > easily lead to bugs when the caller expects a different lifetime.
> >
> > So how about we instead make this a `struct strbuf *referent`? This
> > makes it quite clear who owns the memory. Furthermore, if the caller
> > wants to resolve multiple refs, it would allow them to reuse the buffer
> > for better-optimized allocation patterns.
> 
> Or return an allocated piece of memory via "char **".  I think an
> interface that _requires_ the caller to use strbuf is not nice, if
> the caller is not expected to further _edit_ the returned contents
> using the strbuf API.  If it is likely that the caller would want to
> perform further post-processing on the result, an interface based on
> strbuf is nice, but I do not think it applies to this case.

When iterating through refs this would incur one allocation per ref
though, whereas using a `struct strbuf` would only require a single one.

Patrick

@@ -10,7 +10,7 @@ SYNOPSIS
[verse]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Patrick Steinhardt wrote (reply to this):

On Mon, Apr 08, 2024 at 05:38:13PM +0000, John Cai via GitGitGadget wrote:
> From: John Cai <[email protected]>
> 
> For reftable development, it would be handy to have a tool to provide
> the direct value of any ref whether it be a symbolic ref or not.
> Currently there is git-symbolic-ref, which only works for symbolic refs,
> and git-rev-parse, which will resolve the ref. Let's teach show-ref a
> --symbolic-name option that will cause git-show-ref(1) to print out the
> value symbolic references points to.

I think it was Peff who shared a way to achieve this without actually
introducing a new option via `git for-each-ref --format=`. Can we maybe
provide some benchmarks to demonstrate that this variant is preferable
over what's already possible?

Patrick

> Signed-off-by: John Cai <[email protected]>
> ---
>  Documentation/git-show-ref.txt | 21 ++++++++++++++++++-
>  builtin/show-ref.c             | 38 ++++++++++++++++++++++++----------
>  refs.c                         |  6 ++++++
>  refs.h                         |  2 +-
>  t/t1403-show-ref.sh            | 20 ++++++++++++++++++
>  5 files changed, 74 insertions(+), 13 deletions(-)
> 
> diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
> index ba757470059..9627b34b37f 100644
> --- a/Documentation/git-show-ref.txt
> +++ b/Documentation/git-show-ref.txt
> @@ -10,7 +10,7 @@ SYNOPSIS
>  [verse]
>  'git show-ref' [--head] [-d | --dereference]
>  	     [-s | --hash[=<n>]] [--abbrev[=<n>]] [--tags]
> -	     [--heads] [--] [<pattern>...]
> +	     [--heads] [--symbolic-name] [--] [<pattern>...]
>  'git show-ref' --verify [-q | --quiet] [-d | --dereference]
>  	     [-s | --hash[=<n>]] [--abbrev[=<n>]]
>  	     [--] [<ref>...]
> @@ -58,6 +58,11 @@ OPTIONS
>  	Dereference tags into object IDs as well. They will be shown with `^{}`
>  	appended.
>  
> +--symbolic-name::
> +
> +	Print out the value the reference points to without dereferencing. This
> +	is useful to know the reference that a symbolic ref is pointing to.
> +
>  -s::
>  --hash[=<n>]::
>  
> @@ -146,6 +151,20 @@ $ git show-ref --heads --hash
>  ...
>  -----------------------------------------------------------------------------
>  
> +When using `--symbolic-name`, the output is in the format:
> +
> +-----------
> +<oid> SP <ref> SP <symbolic-name>
> +-----------
> +
> +For example,
> +
> +-----------------------------------------------------------------------------
> +$ git show-ref --symbolic-name
> +b75428bae1d090f60bdd4b67185f814bc8f0819d refs/heads/SYMBOLIC_REF ref:refs/heads/main
> +...
> +-----------------------------------------------------------------------------
> +
>  EXAMPLES
>  --------
>  
> diff --git a/builtin/show-ref.c b/builtin/show-ref.c
> index 1c15421e600..1d681505eac 100644
> --- a/builtin/show-ref.c
> +++ b/builtin/show-ref.c
> @@ -12,7 +12,7 @@
>  static const char * const show_ref_usage[] = {
>  	N_("git show-ref [--head] [-d | --dereference]\n"
>  	   "             [-s | --hash[=<n>]] [--abbrev[=<n>]] [--tags]\n"
> -	   "             [--heads] [--] [<pattern>...]"),
> +	   "             [--heads] [--symbolic-name] [--] [<pattern>...]"),
>  	N_("git show-ref --verify [-q | --quiet] [-d | --dereference]\n"
>  	   "             [-s | --hash[=<n>]] [--abbrev[=<n>]]\n"
>  	   "             [--] [<ref>...]"),
> @@ -26,10 +26,13 @@ struct show_one_options {
>  	int hash_only;
>  	int abbrev;
>  	int deref_tags;
> +	int symbolic_name;
>  };
>  
>  static void show_one(const struct show_one_options *opts,
> -		     const char *refname, const struct object_id *oid)
> +		     const char *refname,
> +		     const char *referent,
> +		     const struct object_id *oid, const int is_symref)
>  {
>  	const char *hex;
>  	struct object_id peeled;
> @@ -44,7 +47,9 @@ static void show_one(const struct show_one_options *opts,
>  	hex = repo_find_unique_abbrev(the_repository, oid, opts->abbrev);
>  	if (opts->hash_only)
>  		printf("%s\n", hex);
> -	else
> +	else if (opts->symbolic_name & is_symref) {
> +		printf("%s %s ref:%s\n", hex, refname, referent);
> +	} else
>  		printf("%s %s\n", hex, refname);
>  
>  	if (!opts->deref_tags)
> @@ -63,8 +68,11 @@ struct show_ref_data {
>  	int show_head;
>  };
>  
> -static int show_ref(const char *refname, const struct object_id *oid,
> -		    int flag UNUSED, void *cbdata)
> +static int show_ref_referent(struct repository *repo UNUSED,
> +			     const char *refname,
> +			     const char *referent,
> +			     const struct object_id *oid,
> +			     int flag, void *cbdata)
>  {
>  	struct show_ref_data *data = cbdata;
>  
> @@ -91,11 +99,17 @@ static int show_ref(const char *refname, const struct object_id *oid,
>  match:
>  	data->found_match++;
>  
> -	show_one(data->show_one_opts, refname, oid);
> +	show_one(data->show_one_opts, refname, referent, oid, flag & REF_ISSYMREF);
>  
>  	return 0;
>  }
>  
> +static int show_ref(const char *refname, const struct object_id *oid,
> +		    int flag, void *cbdata)
> +{
> +	return show_ref_referent(NULL, refname, NULL, oid, flag, cbdata);
> +}
> +
>  static int add_existing(const char *refname,
>  			const struct object_id *oid UNUSED,
>  			int flag UNUSED, void *cbdata)
> @@ -171,10 +185,11 @@ static int cmd_show_ref__verify(const struct show_one_options *show_one_opts,
>  
>  	while (*refs) {
>  		struct object_id oid;
> +		int flags = 0;
>  
>  		if ((starts_with(*refs, "refs/") || refname_is_safe(*refs)) &&
> -		    !read_ref(*refs, &oid)) {
> -			show_one(show_one_opts, *refs, &oid);
> +		    !read_ref_full(*refs, 0, &oid, &flags)) {
> +			show_one(show_one_opts, *refs, NULL, &oid, flags & REF_ISSYMREF);
>  		}
>  		else if (!show_one_opts->quiet)
>  			die("'%s' - not a valid ref", *refs);
> @@ -208,11 +223,11 @@ static int cmd_show_ref__patterns(const struct patterns_options *opts,
>  		head_ref(show_ref, &show_ref_data);
>  	if (opts->heads_only || opts->tags_only) {
>  		if (opts->heads_only)
> -			for_each_fullref_in("refs/heads/", show_ref, &show_ref_data);
> +			for_each_ref_all("refs/heads/", show_ref_referent, &show_ref_data);
>  		if (opts->tags_only)
> -			for_each_fullref_in("refs/tags/", show_ref, &show_ref_data);
> +			for_each_ref_all("refs/tags/", show_ref_referent, &show_ref_data);
>  	} else {
> -		for_each_ref(show_ref, &show_ref_data);
> +		for_each_ref_all("", show_ref_referent, &show_ref_data);
>  	}
>  	if (!show_ref_data.found_match)
>  		return 1;
> @@ -289,6 +304,7 @@ int cmd_show_ref(int argc, const char **argv, const char *prefix)
>  		OPT_BOOL(0, "tags", &patterns_opts.tags_only, N_("only show tags (can be combined with heads)")),
>  		OPT_BOOL(0, "heads", &patterns_opts.heads_only, N_("only show heads (can be combined with tags)")),
>  		OPT_BOOL(0, "exists", &exists, N_("check for reference existence without resolving")),
> +		OPT_BOOL(0, "symbolic-name", &show_one_opts.symbolic_name, N_("print out symbolic reference values")),
>  		OPT_BOOL(0, "verify", &verify, N_("stricter reference checking, "
>  			    "requires exact ref path")),
>  		OPT_HIDDEN_BOOL('h', NULL, &patterns_opts.show_head,
> diff --git a/refs.c b/refs.c
> index 77ae38ea214..9488ad9594d 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -1734,6 +1734,12 @@ int for_each_replace_ref(struct repository *r, each_repo_ref_fn fn, void *cb_dat
>  				    DO_FOR_EACH_INCLUDE_BROKEN, cb_data);
>  }
>  
> +int for_each_ref_all(const char *prefix, each_repo_ref_fn fn, void *cb_data)
> +{
> +	return do_for_each_repo_ref(the_repository, prefix, fn, 0,
> +				    0, cb_data);
> +}
> +
>  int for_each_namespaced_ref(const char **exclude_patterns,
>  			    each_ref_fn fn, void *cb_data)
>  {
> diff --git a/refs.h b/refs.h
> index 23e5aaba2e9..54b459375be 100644
> --- a/refs.h
> +++ b/refs.h
> @@ -337,7 +337,6 @@ int refs_for_each_branch_ref(struct ref_store *refs,
>  			     each_ref_fn fn, void *cb_data);
>  int refs_for_each_remote_ref(struct ref_store *refs,
>  			     each_ref_fn fn, void *cb_data);
> -
>  /* just iterates the head ref. */
>  int head_ref(each_ref_fn fn, void *cb_data);
>  
> @@ -381,6 +380,7 @@ int for_each_tag_ref(each_ref_fn fn, void *cb_data);
>  int for_each_branch_ref(each_ref_fn fn, void *cb_data);
>  int for_each_remote_ref(each_ref_fn fn, void *cb_data);
>  int for_each_replace_ref(struct repository *r, each_repo_ref_fn fn, void *cb_data);
> +int for_each_ref_all(const char *prefix, each_repo_ref_fn fn, void *cb_data);
>  
>  /* iterates all refs that match the specified glob pattern. */
>  int for_each_glob_ref(each_ref_fn fn, const char *pattern, void *cb_data);
> diff --git a/t/t1403-show-ref.sh b/t/t1403-show-ref.sh
> index 33fb7a38fff..0aebe709dca 100755
> --- a/t/t1403-show-ref.sh
> +++ b/t/t1403-show-ref.sh
> @@ -286,4 +286,24 @@ test_expect_success '--exists with existing special ref' '
>  	git show-ref --exists FETCH_HEAD
>  '
>  
> +test_expect_success '--symbolic-name with a non symbolic ref' '
> +	commit_oid=$(git rev-parse refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME) &&
> +	cat >expect <<-EOF &&
> +	$commit_oid refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
> +	EOF
> +	git show-ref --symbolic-name refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME >actual &&
> +	test_cmp expect actual
> +'
> +
> +test_expect_success '--symbolic-name with symbolic ref' '
> +	test_when_finished "git symbolic-ref -d refs/heads/SYMBOLIC_REF_A" &&
> +	commit_oid=$(git rev-parse refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME) &&
> +	cat >expect <<-EOF &&
> +	$commit_oid refs/heads/SYMBOLIC_REF_A ref:refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
> +	EOF
> +	git symbolic-ref refs/heads/SYMBOLIC_REF_A refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME &&
> +	git show-ref --symbolic-name SYMBOLIC_REF_A >actual &&
> +	test_cmp expect actual
> +'
> +
>  test_done
> -- 
> gitgitgadget

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Junio C Hamano wrote (reply to this):

Patrick Steinhardt <[email protected]> writes:

> On Mon, Apr 08, 2024 at 05:38:13PM +0000, John Cai via GitGitGadget wrote:
>> From: John Cai <[email protected]>
>> 
>> For reftable development, it would be handy to have a tool to provide
>> the direct value of any ref whether it be a symbolic ref or not.
>> Currently there is git-symbolic-ref, which only works for symbolic refs,
>> and git-rev-parse, which will resolve the ref. Let's teach show-ref a
>> --symbolic-name option that will cause git-show-ref(1) to print out the
>> value symbolic references points to.
>
> I think it was Peff who shared a way to achieve this without actually
> introducing a new option via `git for-each-ref --format=`. Can we maybe
> provide some benchmarks to demonstrate that this variant is preferable
> over what's already possible?

Yes, I recall that discussion, and in fact I was a bit surprised to
see that this iteration still went to the show-ref route.

Thanks for bringing it up.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, John Cai wrote (reply to this):

Hi Patrick,

On 10 Apr 2024, at 2:53, Patrick Steinhardt wrote:

> On Mon, Apr 08, 2024 at 05:38:13PM +0000, John Cai via GitGitGadget wrote:
>> From: John Cai <[email protected]>
>>
>> For reftable development, it would be handy to have a tool to provide
>> the direct value of any ref whether it be a symbolic ref or not.
>> Currently there is git-symbolic-ref, which only works for symbolic refs,
>> and git-rev-parse, which will resolve the ref. Let's teach show-ref a
>> --symbolic-name option that will cause git-show-ref(1) to print out the
>> value symbolic references points to.
>
> I think it was Peff who shared a way to achieve this without actually
> introducing a new option via `git for-each-ref --format=`. Can we maybe
> provide some benchmarks to demonstrate that this variant is preferable
> over what's already possible?

Yes, it would be better to not introduce a new option. I've done a quick
benchmark including my changes to add the unresolved symref to the iterator, and
some changes to integrate this into ref-filter.c. Here are the results:

$ hyperfine --warmup 5 "git for-each-ref \
--format='%(refname) %(objectname) %(symref)'" "./git for-each-ref \
--format='%(refname) %(objectname) %(symref)'"

Benchmark 1: git for-each-ref --format='%(refname) %(objectname) %(symref)'
  Time (mean ± σ):     213.5 ms ±   9.9 ms    [User: 7.5 ms, System: 14.3 ms]
  Range (min … max):   202.7 ms … 236.3 ms    14 runs

Benchmark 2: ./git for-each-ref --format='%(refname) %(objectname) %(symref)'
  Time (mean ± σ):      10.8 ms ±   1.3 ms    [User: 4.4 ms, System: 6.2 ms]
  Range (min … max):     9.5 ms …  17.5 ms    189 runs

Summary
  ./git for-each-ref --format='%(refname) %(objectname) %(symref)' ran
   19.72 ± 2.62 times faster than git for-each-ref --format='%(refname) %(objectname) %(symref)'

It looks like this gives us a nice speedup. I will send up a new version that improves git-for-each-ref
instead.

thanks
John

>
> Patrick
>
>> Signed-off-by: John Cai <[email protected]>
>> ---
>>  Documentation/git-show-ref.txt | 21 ++++++++++++++++++-
>>  builtin/show-ref.c             | 38 ++++++++++++++++++++++++----------
>>  refs.c                         |  6 ++++++
>>  refs.h                         |  2 +-
>>  t/t1403-show-ref.sh            | 20 ++++++++++++++++++
>>  5 files changed, 74 insertions(+), 13 deletions(-)
>>
>> diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
>> index ba757470059..9627b34b37f 100644
>> --- a/Documentation/git-show-ref.txt
>> +++ b/Documentation/git-show-ref.txt
>> @@ -10,7 +10,7 @@ SYNOPSIS
>>  [verse]
>>  'git show-ref' [--head] [-d | --dereference]
>>  	     [-s | --hash[=<n>]] [--abbrev[=<n>]] [--tags]
>> -	     [--heads] [--] [<pattern>...]
>> +	     [--heads] [--symbolic-name] [--] [<pattern>...]
>>  'git show-ref' --verify [-q | --quiet] [-d | --dereference]
>>  	     [-s | --hash[=<n>]] [--abbrev[=<n>]]
>>  	     [--] [<ref>...]
>> @@ -58,6 +58,11 @@ OPTIONS
>>  	Dereference tags into object IDs as well. They will be shown with `^{}`
>>  	appended.
>>
>> +--symbolic-name::
>> +
>> +	Print out the value the reference points to without dereferencing. This
>> +	is useful to know the reference that a symbolic ref is pointing to.
>> +
>>  -s::
>>  --hash[=<n>]::
>>
>> @@ -146,6 +151,20 @@ $ git show-ref --heads --hash
>>  ...
>>  -----------------------------------------------------------------------------
>>
>> +When using `--symbolic-name`, the output is in the format:
>> +
>> +-----------
>> +<oid> SP <ref> SP <symbolic-name>
>> +-----------
>> +
>> +For example,
>> +
>> +-----------------------------------------------------------------------------
>> +$ git show-ref --symbolic-name
>> +b75428bae1d090f60bdd4b67185f814bc8f0819d refs/heads/SYMBOLIC_REF ref:refs/heads/main
>> +...
>> +-----------------------------------------------------------------------------
>> +
>>  EXAMPLES
>>  --------
>>
>> diff --git a/builtin/show-ref.c b/builtin/show-ref.c
>> index 1c15421e600..1d681505eac 100644
>> --- a/builtin/show-ref.c
>> +++ b/builtin/show-ref.c
>> @@ -12,7 +12,7 @@
>>  static const char * const show_ref_usage[] = {
>>  	N_("git show-ref [--head] [-d | --dereference]\n"
>>  	   "             [-s | --hash[=<n>]] [--abbrev[=<n>]] [--tags]\n"
>> -	   "             [--heads] [--] [<pattern>...]"),
>> +	   "             [--heads] [--symbolic-name] [--] [<pattern>...]"),
>>  	N_("git show-ref --verify [-q | --quiet] [-d | --dereference]\n"
>>  	   "             [-s | --hash[=<n>]] [--abbrev[=<n>]]\n"
>>  	   "             [--] [<ref>...]"),
>> @@ -26,10 +26,13 @@ struct show_one_options {
>>  	int hash_only;
>>  	int abbrev;
>>  	int deref_tags;
>> +	int symbolic_name;
>>  };
>>
>>  static void show_one(const struct show_one_options *opts,
>> -		     const char *refname, const struct object_id *oid)
>> +		     const char *refname,
>> +		     const char *referent,
>> +		     const struct object_id *oid, const int is_symref)
>>  {
>>  	const char *hex;
>>  	struct object_id peeled;
>> @@ -44,7 +47,9 @@ static void show_one(const struct show_one_options *opts,
>>  	hex = repo_find_unique_abbrev(the_repository, oid, opts->abbrev);
>>  	if (opts->hash_only)
>>  		printf("%s\n", hex);
>> -	else
>> +	else if (opts->symbolic_name & is_symref) {
>> +		printf("%s %s ref:%s\n", hex, refname, referent);
>> +	} else
>>  		printf("%s %s\n", hex, refname);
>>
>>  	if (!opts->deref_tags)
>> @@ -63,8 +68,11 @@ struct show_ref_data {
>>  	int show_head;
>>  };
>>
>> -static int show_ref(const char *refname, const struct object_id *oid,
>> -		    int flag UNUSED, void *cbdata)
>> +static int show_ref_referent(struct repository *repo UNUSED,
>> +			     const char *refname,
>> +			     const char *referent,
>> +			     const struct object_id *oid,
>> +			     int flag, void *cbdata)
>>  {
>>  	struct show_ref_data *data = cbdata;
>>
>> @@ -91,11 +99,17 @@ static int show_ref(const char *refname, const struct object_id *oid,
>>  match:
>>  	data->found_match++;
>>
>> -	show_one(data->show_one_opts, refname, oid);
>> +	show_one(data->show_one_opts, refname, referent, oid, flag & REF_ISSYMREF);
>>
>>  	return 0;
>>  }
>>
>> +static int show_ref(const char *refname, const struct object_id *oid,
>> +		    int flag, void *cbdata)
>> +{
>> +	return show_ref_referent(NULL, refname, NULL, oid, flag, cbdata);
>> +}
>> +
>>  static int add_existing(const char *refname,
>>  			const struct object_id *oid UNUSED,
>>  			int flag UNUSED, void *cbdata)
>> @@ -171,10 +185,11 @@ static int cmd_show_ref__verify(const struct show_one_options *show_one_opts,
>>
>>  	while (*refs) {
>>  		struct object_id oid;
>> +		int flags = 0;
>>
>>  		if ((starts_with(*refs, "refs/") || refname_is_safe(*refs)) &&
>> -		    !read_ref(*refs, &oid)) {
>> -			show_one(show_one_opts, *refs, &oid);
>> +		    !read_ref_full(*refs, 0, &oid, &flags)) {
>> +			show_one(show_one_opts, *refs, NULL, &oid, flags & REF_ISSYMREF);
>>  		}
>>  		else if (!show_one_opts->quiet)
>>  			die("'%s' - not a valid ref", *refs);
>> @@ -208,11 +223,11 @@ static int cmd_show_ref__patterns(const struct patterns_options *opts,
>>  		head_ref(show_ref, &show_ref_data);
>>  	if (opts->heads_only || opts->tags_only) {
>>  		if (opts->heads_only)
>> -			for_each_fullref_in("refs/heads/", show_ref, &show_ref_data);
>> +			for_each_ref_all("refs/heads/", show_ref_referent, &show_ref_data);
>>  		if (opts->tags_only)
>> -			for_each_fullref_in("refs/tags/", show_ref, &show_ref_data);
>> +			for_each_ref_all("refs/tags/", show_ref_referent, &show_ref_data);
>>  	} else {
>> -		for_each_ref(show_ref, &show_ref_data);
>> +		for_each_ref_all("", show_ref_referent, &show_ref_data);
>>  	}
>>  	if (!show_ref_data.found_match)
>>  		return 1;
>> @@ -289,6 +304,7 @@ int cmd_show_ref(int argc, const char **argv, const char *prefix)
>>  		OPT_BOOL(0, "tags", &patterns_opts.tags_only, N_("only show tags (can be combined with heads)")),
>>  		OPT_BOOL(0, "heads", &patterns_opts.heads_only, N_("only show heads (can be combined with tags)")),
>>  		OPT_BOOL(0, "exists", &exists, N_("check for reference existence without resolving")),
>> +		OPT_BOOL(0, "symbolic-name", &show_one_opts.symbolic_name, N_("print out symbolic reference values")),
>>  		OPT_BOOL(0, "verify", &verify, N_("stricter reference checking, "
>>  			    "requires exact ref path")),
>>  		OPT_HIDDEN_BOOL('h', NULL, &patterns_opts.show_head,
>> diff --git a/refs.c b/refs.c
>> index 77ae38ea214..9488ad9594d 100644
>> --- a/refs.c
>> +++ b/refs.c
>> @@ -1734,6 +1734,12 @@ int for_each_replace_ref(struct repository *r, each_repo_ref_fn fn, void *cb_dat
>>  				    DO_FOR_EACH_INCLUDE_BROKEN, cb_data);
>>  }
>>
>> +int for_each_ref_all(const char *prefix, each_repo_ref_fn fn, void *cb_data)
>> +{
>> +	return do_for_each_repo_ref(the_repository, prefix, fn, 0,
>> +				    0, cb_data);
>> +}
>> +
>>  int for_each_namespaced_ref(const char **exclude_patterns,
>>  			    each_ref_fn fn, void *cb_data)
>>  {
>> diff --git a/refs.h b/refs.h
>> index 23e5aaba2e9..54b459375be 100644
>> --- a/refs.h
>> +++ b/refs.h
>> @@ -337,7 +337,6 @@ int refs_for_each_branch_ref(struct ref_store *refs,
>>  			     each_ref_fn fn, void *cb_data);
>>  int refs_for_each_remote_ref(struct ref_store *refs,
>>  			     each_ref_fn fn, void *cb_data);
>> -
>>  /* just iterates the head ref. */
>>  int head_ref(each_ref_fn fn, void *cb_data);
>>
>> @@ -381,6 +380,7 @@ int for_each_tag_ref(each_ref_fn fn, void *cb_data);
>>  int for_each_branch_ref(each_ref_fn fn, void *cb_data);
>>  int for_each_remote_ref(each_ref_fn fn, void *cb_data);
>>  int for_each_replace_ref(struct repository *r, each_repo_ref_fn fn, void *cb_data);
>> +int for_each_ref_all(const char *prefix, each_repo_ref_fn fn, void *cb_data);
>>
>>  /* iterates all refs that match the specified glob pattern. */
>>  int for_each_glob_ref(each_ref_fn fn, const char *pattern, void *cb_data);
>> diff --git a/t/t1403-show-ref.sh b/t/t1403-show-ref.sh
>> index 33fb7a38fff..0aebe709dca 100755
>> --- a/t/t1403-show-ref.sh
>> +++ b/t/t1403-show-ref.sh
>> @@ -286,4 +286,24 @@ test_expect_success '--exists with existing special ref' '
>>  	git show-ref --exists FETCH_HEAD
>>  '
>>
>> +test_expect_success '--symbolic-name with a non symbolic ref' '
>> +	commit_oid=$(git rev-parse refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME) &&
>> +	cat >expect <<-EOF &&
>> +	$commit_oid refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
>> +	EOF
>> +	git show-ref --symbolic-name refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME >actual &&
>> +	test_cmp expect actual
>> +'
>> +
>> +test_expect_success '--symbolic-name with symbolic ref' '
>> +	test_when_finished "git symbolic-ref -d refs/heads/SYMBOLIC_REF_A" &&
>> +	commit_oid=$(git rev-parse refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME) &&
>> +	cat >expect <<-EOF &&
>> +	$commit_oid refs/heads/SYMBOLIC_REF_A ref:refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
>> +	EOF
>> +	git symbolic-ref refs/heads/SYMBOLIC_REF_A refs/heads/$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME &&
>> +	git show-ref --symbolic-name SYMBOLIC_REF_A >actual &&
>> +	test_cmp expect actual
>> +'
>> +
>>  test_done
>> -- 
>> gitgitgadget

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant