On Thu, Jun 14, 2018 at 12:52:25AM +0200, Christian Hesse wrote: > From: Christian Hesse <m...@eworm.de> > > Update to git version v2.18.0-rc2. Required changes follow upstream commits: > > * Convert find_unique_abbrev* to struct object_id > (aab9583f7b5ea5463eb3f653a0b4ecac7539dc94) > * sha1_file: convert read_sha1_file to struct object_id > (b4f5aca40e6f77cbabcbf4ff003c3cf30a1830c8) > * sha1_file: convert sha1_object_info* to object_id > (abef9020e3df87c441c9a3a95f592fce5fa49bb9) > * object-store: move packed_git and packed_git_mru to object store > (a80d72db2a73174b3f22142eb2014b33696fd795) > * treewide: rename tree to maybe_tree > (891435d55da80ca3654b19834481205be6bdfe33) > > The changed data types required some of our own functions to be converted > to struct object_id: > > ls_item > print_dir > print_dir_entry > print_object > single_tree_cb > walk_tree > write_tree_link > > And finally we use new upstream functions that were added for > struct object_id: > > hashcpy -> oidcpy > sha1_to_hex -> oid_to_hex > > Signed-off-by: Christian Hesse <m...@eworm.de>
With Andy's fix, Reviewed-by: John Keeping <j...@keeping.me.uk> It looks like our interface to libgit.a is completely converted to struct object_id after this update! But we still have a few mentions of sha1 in our code. Most of this is sha1 and sha2 in struct cgit_query, but these aren't actually hashes most of the time, they can be any object reference that Git understands, so I think we should rename them to ref1 and ref2 (along with has_sha1 -> has_ref). What do you think? (ui-blob does require sha1 to be hex, but it's a bit of a special case anyway and I think it's fine to impose an extra requirement there.) After that, I think all that's left is parsing.c and there's no reason to do anything there until we now how newhash will alter the commit and tag object encodings. _______________________________________________ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
