On Mon, Jan 13, 2025 at 12:17:01AM -0500, Jeff King wrote: > diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c > index 42f34e1236..ed38b82346 100644 > --- a/builtin/ls-remote.c > +++ b/builtin/ls-remote.c > @@ -61,6 +61,7 @@ int cmd_ls_remote(int argc, > const struct ref *ref; > struct ref_array ref_array; > struct ref_sorting *sorting; > + struct ref_format format = REF_FORMAT_INIT; > struct string_list sorting_options = STRING_LIST_INIT_DUP; This caller in ls-remote is the only one that doesn't otherwise have a ref_format struct. I don't think it's a big deal to add one like this, and it might even be nice to support --format. But I suspect there are other weird errors lurking (however we structure this code) because we may not actually have access to the objects! The ahead-behind atom seems to gloss over that, but others will barf. Interestingly we detect the out-of-repo case: $ git ls-remote --sort=authordate git.git fatal: not a git repository, but the field 'authordate' requires access to object data but not if we have a repo: $ git init $ git ls-remote --sort=authordate git.git fatal: missing object 978601ccf7b27399aa349c535b29965e664046c4 for refs/heads/ci-config I guess it would work _sometimes_ if you've fetched recently from the remote. So maybe it does not make sense to outlaw all object-inspecting atoms for ls-remote, and just say that the error above is the best we can do? It does get weird with ahead-behind, though, as you'll get a different sort order depending on whether you've actually fetched the object. Anyway, all orthogonal to what you're fixing, but kind of gross none the less. -Peff
