Re: [PATCH v3 02/20] commit-graph: fix GRAPH_MIN_SIZE
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Jun 2, 2018, 19:43 UTC
- Message-ID
- <86lgbxq8it.fsf@gmail.com>
- In-Reply-To
- <20180526203036.GL652292@genre.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 16 quoted lines
> 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