Re: [PATCH 2/5] sha1_file: fix hardcoded size in null_sha1

From: Patryk Obara <patryk.obara@gmail.com>
Date: Aug 16, 2017, 12:11 UTC
Message-ID: <CAJfL8+R6SK3RGEGXcr5N-btKKjHCUcT95r7oOOsWgY1RXwEEtA@mail.gmail.com>
In-Reply-To: <xmqqbmngr6wq.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> wrote:

Show 6 quoted lines

> I said this is OK for "null" because we assume we will use ^\0{len}$
> for any hash function we choose as the "impossible" value, and for
> that particular use pattern, we do not need such a union.  Just
> letting the caller peek at an appropriate number of bytes at the
> beginning of that NUL buffer for hash the caller wants to use is
> sufficient.

Do you think I should record this explanation as either commit message or comment in sha1_file.c?

> MAX is inevitable only if we envision that we have to handle objects
> named using two or more hashing schemes at the same time, with the
> same binary and during the same run inside a single process.

I think this will be the case if "transition one local repository at a time" from Jonathan Nieder's transition plan will be followed. This plan assumes object_id translation happening e.g. during fetch operation.

-- 
| ← Ceci n'est pas une pipe
Patryk Obara