Re: [PATCH 00/17] object_id part 14

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Jul 14, 2018, 23:38 UTC
Message-ID: <CAMy9T_HuO1a1_R+avedw-dmV4uWjOU9f0Hkrfo=gk8HTXcA7AQ@mail.gmail.com>
In-Reply-To: <1438bdfd-cb13-8da4-2dd2-16362b242ff3@gmail.com>

On Mon, Jul 9, 2018 at 6:15 AM Derrick Stolee <stolee@gmail.com> wrote:

Show 18 quoted lines

> On 7/8/2018 11:12 PM, Jacob Keller wrote:
> > On Sun, Jul 8, 2018 at 4:39 PM brian m. carlson
> > <sandals@crustytoothpaste.net> wrote:
> >> This is the fourteenth series of patches to switch to using struct
> >> object_id and the_hash_algo.  This series converts several core pieces
> >> to use struct object_id, including the oid* and hex functions.
> >>
> >> All of these patches have been tested with both SHA-1 and a 256-bit
> >> hash.
> >>
> > I read through the series, and didn't spot anything odd, except for
> > the question about reasoning for why we use memcmp directly over using
> > hashcmp. I don't think that's any sort of blocker, it just seemed an
> > odd decision to me.
>
> I also read through the series and only found the 100/200 constants
> confusing. Not worth blocking on, but I'm CC'ing Michael Haggerty to
> comment if he knows how the magic 100 was computed.

The magic 100 blames back to our chief magician, Junio:

    8ac65937d0 Make sure we do not write bogus reflog entries. (2007-01-26)

Since then, as far as I can tell, it's just been copy-pasted forward. It would be easy to compute it precisely based on the length of the two OIDs, represented as hex strings, plus the few extra characters in the format string.

Michael