On Tue, Aug 31, 2021 at 09:33:38AM -0700, Junio C Hamano wrote: > 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 think the point is that most people _do_ still live in that world. They have not started using the new hash algorithm yet, and what they have been doing for years will continue to work. Likewise, once they switch, things will continue to work as long as each repo's alternates use the same hash. So my reasoning was less "this is useful, and a good idea" and more "it works now, and will probably continue to work OK in practice, so taking it away will probably bother people". Now if somebody wants to make an argument that they are not actually workable now, I could buy that. ;) You cannot even run "pack-objects" without a repository, though it is not too hard to copy the result around. > > 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. Yes, I think that would be an improvement. I just don't find it all that urgent, since they're likely to get an error anyway (just probably one that is more mysterious). Given the work involved to even detect the situation, it doesn't seem like that high a priority to me. -Peff
