Re: [PATCH] show-ref: add --unresolved option

[Patrick Steinhardt <ps@pks.im>]

[-- Attachment #1: Type: text/plain, Size: 2400 bytes --]

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 <johncai86@gmail.com>
> > 
> > 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]