On Wed, Jul 19, 2017 at 4:56 PM, Jonathan Tan <jonathantanmy@xxxxxxxxxx> wrote: > On Tue, 11 Jul 2017 15:06:11 -0700 > Stefan Beller <sbeller@xxxxxxxxxx> wrote: > >> On Tue, Jul 11, 2017 at 12:48 PM, Jonathan Tan <jonathantanmy@xxxxxxxxxx> 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@xxxxxxxxxx> >> >> 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
