Jeff King <peff@xxxxxxxx> writes: >> 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.
