Taylor Blau <me@xxxxxxxxxxxx> writes:
> On Mon, Aug 30, 2021 at 03:28:47PM -0700, Junio C Hamano wrote:
>> "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes:
>>
>> > Yeah, this is a possible problem. You can also see it when using git
>> > index-pack outside of a repository with an incorrect --object-format
>> > option.
>> >
>> > I'm not sure how folks want to deal with that; I'm just fine saying,
>> > "Well, don't do that," but other folks may have different opinions.
>>
>> OK, so if we go back to the original breakage of the test script
>> that triggered this discussion, the right solution would be to make
>> sure both test repositories/object stores are prepared with the
>> algorithm specified with GIT_TEST_DEFAULT_HASH?
>
> Just to make sure do you still see this as a separate issue from running
> the midx builtin outside of a repository?
They are separate issues, but the .midx issue has a small overlap
with the much bigger "do not mix repositories and object stores with
different hashes" issue.
The users of raw object stores (e.g. $GIT_OBJECT_DIRECTORIES,
"--object-dir", there may be others) need to be updated so that the
code paths involved can reliably learn what hash algorithm is used
and other traits that may not be available in the object store alone
(e.g. refs might be relevant if the using code needs to learn which
objects are still reachable) for the latter. It would need a couple
of things that are fairly isolated to solve, I would imagine:
(1) convention to either tie a raw object store with its repository
or declare a raw object store is unusable because "other
traits" are not found for it.
(2) given a repository, inspect it and decide if it is "compatible"
with the current repository.
(3) update code paths involved in prepare_alt_odb() to use (1) and
(2) to inspect and reject incompatible object store as
alternate.
And once we have that, "git multi-pack-index --object-dir=X" can use
(1) and (2) for the same "Is this other object store compatible with
the current repository?" check, no?
The other side of the coin is that midx needs to do equivalents of
(1) and (2) anyway, and the required amount of the work for (3)
smells a lot smaller than work for (1) and (2). (3) may be just a
matter of "add a call to is_odb_compatible(dir) for the directory
being added as an alt odb", and the same single validation call may
be all it needs on the --object-dir argument on the midx side.
I think it makes sense for the midx command to require being in a
repository to run (to establish what "the current repository" is)
and insist on the other object store given with --object-dir to be
"compatible" with the current repository (i.e. the same hash
algorithm, there may be others). I am a bit fuzzy why we want it
to be already our alternate.
Thanks.
