On Wed, Oct 17, 2018 at 12:44 AM brian m. carlson
<sandals@xxxxxxxxxxxxxxxxxxxx> wrote:
> > > >> static uint8_t oid_version(void)
> > > >> {
> > > >> - return 1;
> > > >> + switch (hash_algo_by_ptr(the_hash_algo)) {
> > > >> + case GIT_HASH_SHA1:
> > > >> + return 1;
> > > >> + case GIT_HASH_SHA256:
> > > >> + return 2;
> > > > Should we just increase this field to uint32_t and store format_id
> > > > instead? That will keep oid version unique in all data formats.
> > > Both the commit-graph and multi-pack-index store a single byte for the
> > > hash version, so that ship has sailed (without incrementing the full
> > > file version number in each format).
> >
> > And it's probably premature to add the oid version field when multiple
> > hash support has not been fully realized. Now we have different ways
> > of storing hash id and need separate mappings.
>
> Honestly, anything in the .git directory that is not the v3 pack indexes
> or the loose object file should be in exactly one hash algorithm. We
> could simply just leave this value at 1 all the time and ignore the
> field, since we already know what algorithm it will use.
In this particular case, I agree, but not as a general principle. It's
nice to have independence for fsck-like tools. I don't know if we have
a tool that simply validates commit-graph file format (and not trying
to access any real object). But for such a tool, I guess we can just
pass the hash algorithm from command line. The user would have to
guess a bit.
--
Duy
