On Mon, Feb 26, 2018 at 4:11 AM, brian m. carlson
<sand...@crustytoothpaste.net> wrote:
> @@ -44,7 +44,7 @@ void resolve_undo_write(struct strbuf *sb, struct
> string_list *resolve_undo)
> for (i = 0; i < 3; i++) {
> if (!ui->mode[i])
> continue;
> - strbuf_add(sb, ui->sha1[i], 20);
> + strbuf_add(sb, ui->oid[i].hash, the_hash_algo->rawsz);
> }
> }
> }
> @@ -89,7 +89,7 @@ struct string_list *resolve_undo_read(const char *data,
> unsigned long size)
> continue;
> if (size < 20)
> goto error;
> - hashcpy(ui->sha1[i], (const unsigned char *)data);
> + hashcpy(ui->oid[i].hash, (const unsigned char *)data);
> size -= 20;
> data += 20;
> }
Here we see the same pattern again, but this time the @@ lines give
better context: these are actually hash I/O. Maybe it's about time we
add
int oidwrite(char *, size_t , const struct object_id *);
// optionally, void strbuf_addoid(struct strbuf *, const struct object_id *);
int oidread(struct object_id *, const char *, size_t);
for conversion from between an object_id in memory and on disk? It
would probably be a straight memcpy for all hash algorithms so we
don't really need new function pointers in git_hash_algo for this.
--
Duy
