List for cgit developers and users
 help / color / mirror / Atom feed
From: john at keeping.me.uk (John Keeping)
Subject: [PATCH 1/1] RFC: git: update to v2.18.0-rc2
Date: Sat, 16 Jun 2018 17:14:09 +0100	[thread overview]
Message-ID: <20180616161409.GB1922@john.keeping.me.uk> (raw)
In-Reply-To: <20180613225225.9945-1-list@eworm.de>

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.


  parent reply	other threads:[~2018-06-16 16:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-13 22:52 list
2018-06-14  1:48 ` [PATCH] ui-shared: typename changed to type_name in git 2.18.0-rc2 andy
2018-06-16 16:14 ` john [this message]
2018-06-16 16:15   ` [PATCH 1/1] RFC: git: update to v2.18.0-rc2 Jason
2018-06-16 20:34   ` list
2018-06-18  6:10 ` list
2018-06-18  6:42   ` andy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180616161409.GB1922@john.keeping.me.uk \
    --to=cgit@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).