Subject: Re: [PATCH] ref-filter: share bases and is_base_tips between formatting and sorting

From: Jeff King <[email-masked]>
Date: Mon, 13 Jan 2025 00:23:13 -0500

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