[PATCH 1/1] RFC: git: update to v2.18.0-rc2
John Keeping
john at keeping.me.uk
Sat Jun 16 18:14:09 CEST 2018
On Thu, Jun 14, 2018 at 12:52:25AM +0200, Christian Hesse wrote:
> From: Christian Hesse <mail at 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 <mail at eworm.de>
With Andy's fix,
Reviewed-by: John Keeping <john at 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.
More information about the CGit
mailing list