On Tue, Jan 22 2019, Jeff King wrote: > On Fri, Jan 18, 2019 at 11:26:29PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> I stand corrected, I thought these still needed to be updated to parse >> anything that wasn't 40 chars, since I hadn't seen anything about these >> formats in the hash transition document. >> >> So fair enough, let's change that while we're at it, but this seems like >> something that needs to be planned for in more detail / documented in >> the hash transition doc. >> >> I.e. many (e.g. me) maintain some system-wide skiplist for strict fsck >> cloning of legacy repos. So I can see there being some need for a >> SHA1<->SHA256 map in this case, but since these files might stretch >> across repo boundaries and not be checked into the repo itself this is a >> new use-case that needs thinking about. > > My assumption had been that changing your local repository would be a > (local) flag day, and you'd update any ancillary files like skiplists, > mailmap.blob, etc at the same time. I'm not opposed to making those > features more clever, though. > >> But now that I think about it this sort of thing would be a good >> use-case for just fixing these various historical fsck issues while >> we're at it when possible, e.g. "missing space before email" (probably >> not all could be unambiguously fixed). So instead of sha256<->sha1 >> fn(sha256)<->fn(sha1)[1]? > > That is a very tempting thing to do, but I think it comes with its own > complications. We do not want to do fn(sha1), I don't think; the reason > we care about sha1 at all is that those hashes are already set in stone. > > There could be a "clean up the data as we convert to sha256" operation, > but: > > - it needs to be set in stone from day 1, I'd think. The last thing we > want is to modify it after conversions are in the wild > > - I think we need to be bi-directional. So it must be a mapping that > can be undone to retrieve the original bytes, so we can compute > their "real" sha1. It needing to be bidirectional is a very good point, and I think that makes my suggestion a non-starter. Thanks. > At which point, I think it might be simpler to just make git more > permissive with respect to those minor data errors (and in fact, we are > already pretty permissive for the most part in non-fsck operations). Yeah it's probably better to make some of these "errors" softer warnings. The X-Y issue I have is that I turned on transfer.fsckObjects, so then I can't clone repos with various minor historical issues in commit headers etc., so I maintain a big skip list. But what I was actually after was fsck checks like the .gitmodules security check. Of course I could chase them all down and turn them into warn/error/ignore individually, but it would be better if we e.g. had some way to say "serious things error, minor things warn", maybe with the option of only having the looser version on fetch but not recieve with the principle that we should be loose in what we accept from existing data but strict with new data #leftoverbits
