"brian m. carlson" <sand...@crustytoothpaste.net> writes: > On Sat, May 26, 2018 at 08:46:09PM +0200, Jakub Narebski wrote: >> One issue: in the future when Git moves to NewHash, it could encounter >> then both commit-graph files using SHA-1 and using NewHash. What about >> GRPH_OID_LEN then: for one of those it would be incorrect. Unless it is >> about minimal length of checksum, that is we assume that NewHash would >> be longer than SHA-1, but ten why name it GRAPH_OID_LEN? > > My proposal is that whatever we're using in the .git directory is > consistent. If we're using SHA-1 for objects, then everything is SHA-1. > If we're using NewHash for objects, then all data is stored in NewHash > (except translation tables and such). Any conversions between SHA-1 and > NewHash require a lookup through the standard techniques. > > I agree that here it would be more helpful if it were a reference to > the_hash_algo, and I've applied a patch to my object-id-part14 series to > make that conversion.
All right, I can agree that it would make most sense to always use SHA-1 for OID, or always use NewHash for objects. This would make commit-graph file with SHA-1 hash invalid for NewHash-using Git version. It would be nice, however, to avoid having to redo all the hard work, like calculating generation numbers (from old commit-graph file, or from server that does not support NewHash yet -- the latter is not implemented, but IIUC planned feature). But we can do it with explicit conversion step, e.g. 'git commit-graph convert' or 'upgrade'. But all that is in the future. -- Jakub Narębski
