Re: [RFC PATCH 2/3] sha1-array: support appending unsigned char hash
- From
Stefan Beller <sbeller@google.com>
- Date
- Jul 20, 2017, 00:06 UTC
- Message-ID
- <CAGZ79kYCr_Ozt3sa5FffgY-kzwAnGc2rTFEQ1AzeruURXQsYmA@mail.gmail.com>
- In-Reply-To
- <20170719165622.78e463fd@twelve2.svl.corp.google.com>
On Wed, Jul 19, 2017 at 4:56 PM, Jonathan Tan <jonathantanmy@google.com> wrote:
Show 16 quoted lines
> On Tue, 11 Jul 2017 15:06:11 -0700 > Stefan Beller <sbeller@google.com> wrote: > >> On Tue, Jul 11, 2017 at 12:48 PM, Jonathan Tan <jonathantanmy@google.com> wrote: >> > In a subsequent patch, sha1_file will need to append object names in the >> > form of "unsigned char *" to oid arrays. Teach sha1-array support for >> > that. >> > >> > Signed-off-by: Jonathan Tan <jonathantanmy@google.com> >> >> This breaks the oid/sha1 barrier? > > Not sure what you mean by this. This patch is meant to be a change to > make "unsigned char *"-using code able to create/modify oid arrays, > while we migrate away from "unsigned char *" - I don't know of any > barrier.
In my mind we have 2 states: * the current state where we have "char *sha1" * the future in which we have "struct object_id oid"
In both realms you can do things (and the current code base has examples for both), but these 2 are connected via only a couple well defined functions (sha1_to_hex, oid_to_sha1) during the conversion phase.
So with that mindset I was slightly irritated to see a function that uses both realms so interchangeably.
Revisiting that it is actually not that bad, but also a good idea to have in the transition phase.
Sorry for the noise, Stefan