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

From: Jeff King <peff@peff.net>
Date: Jan 13, 2025, 05:23 UTC
Message-ID: <20250113052313.GA768703@coredump.intra.peff.net>
In-Reply-To: <20250113051700.GA767856@coredump.intra.peff.net>

On Mon, Jan 13, 2025 at 12:17:01AM -0500, Jeff King wrote:

Show 10 quoted lines

> 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