> Placing a reprepare_packed_git() call inside chck_connected() before
> looping through the packed_git list seems like the safest way to
> avoid this issue in the future. While reprepare_packed_git() does
> another scan of the pack directory, it is not terribly expensive as
> long as we do not run it in a loop. We check connectivity only a
> few times per command, so this will not have a meaningful performance
> impact. In exchange, we get extra safety around this check.
This also means that check_connected() now does the equivalent of
reprepare_packed_git() in both its branches (the rev-list one, which
spawns a new process and thus rereads the pack directory, and the fast
one). This will at least help callers to reason about its behavior more
simply, so it sounds like a good change to me.
> I included how I found this (integrating v2.26.0-rc0 into Scalar), but I
> am able to reproduce it on my Linux machine using real fetches from
> github.com. I'm not sure why I was unable to reproduce the issue in test
> cases using the file:// URLs or the HTTP tests.
If you remember how to reproduce it using real fetches from github.com,
could you give us reproduction steps?
Thanks for attempting to reproduce it in a test script.
> diff --git a/connected.c b/connected.c
> index 7e9bd1bc622..ac52b07b474 100644
> --- a/connected.c
> +++ b/connected.c
> @@ -61,7 +61,11 @@ int check_connected(oid_iterate_fn fn, void *cb_data,
> * object is a promisor object. Instead, just make sure we
> * received, in a promisor packfile, the objects pointed to by
> * each wanted ref.
> + *
> + * Before checking for promisor packs, be sure we have the
> + * latest pack-files loaded into memory.
> */
> + reprepare_packed_git(the_repository);
> do {
> struct packed_git *p;
The code itself looks good to me.
