Re: [PATCH v4 05/25] midx: clear auxiliary .rev after replacing the MIDX

Jeff King [off-list ref] writes:

quoted

I think taking a look to see if ../config exists to use the data
might be helpful for some cases, but should not be a blocker for
completing the requested operation. The config from the non-alternate
repo should be sufficient for this (somewhat strange) case.

Yes, agreed. We have long supported these kind of "bare" alternates, and
I wouldn't be surprised if they are in wide use (though I do wonder how
folks actually modify them, since most commands that touch objects
really do want to be in a repository).

I kind of find the above two somewhat surprising, but I am willing
to go with the less safer option if that is what people want.

It has been perfectly OK in the pre-alternative-hash-algorithms
world, but we no longer live in such a world, so we'd need to come
up with a way to keep using alternates in a safer way.

I do not see the reasoning behind "should not be a blocker" from
Derrick substantiated.  What's the reason why that raw object store
cannot come from an existing repository, and what's the benefit we
get from not having to have a repository there?

The natural extension for the hash-format problem would probably be to
call check_repository_format_gently() on the parent directory of the
alternate-objects dir. If it succeeds, then we can pull out the
hash_algo parameter from its repository_format struct. And if not, then
we just assume it matches the main repo.

But I suspect all of this is moot for now, beyond being able to return a
nicer error message. The rest of the code is not at all ready to handle
packs with two different hashes in the same process.

I do not think it is all that urgent to make it possible for packs
with different algorithms to be used.  It is sufficient to _ignore_
(or error out) configured odb that is incompatible with the current
repository.

Thanks.