From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org,
"brian m. carlson" <sandals@crustytoothpaste.net>
Subject: Re: [PATCH 2/2] hex: drop sha1_to_hex()
Date: Tue, 12 Nov 2019 12:44:58 +0100 [thread overview]
Message-ID: <20191112114458.GP4348@szeder.dev> (raw)
In-Reply-To: <20191112105759.GA9714@sigill.intra.peff.net>
On Tue, Nov 12, 2019 at 05:57:59AM -0500, Jeff King wrote:
> On Tue, Nov 12, 2019 at 01:13:58PM +0900, Junio C Hamano wrote:
>
> > >> We can't use oid_to_hex() because we don't have a 'struct object_id'
> > >> in the first place, as sha1dc only ever deals with 20 unsigned chars.
> > >
> > > Ah, you're right. I admit I am still getting up to speed on all of the
> > > new hash-agnostic versions of the various functions.
> >
> > Thanks. I've amended this one and the range diff since the pushout
> > yesterday looks like this.
>
> Thanks. This first hunk is what I would have done:
>
> > 1: 8a030f1796 ! 1: 02d21d4117 hex: drop sha1_to_hex()
> > @@ Commit message
> > hex: drop sha1_to_hex()
> >
> > There's only a single caller left of sha1_to_hex(), since everybody now
> > - uses oid_to_hex() instead. This case is in the sha1dc wrapper, where we
> > + uses hash_to_hex() instead. This case is in the sha1dc wrapper, where we
> > print a hex sha1 when we find a collision. This one will always be sha1,
> > - regardless of the current hash algorithm, so we can't use oid_to_hex()
> > + regardless of the current hash algorithm, so we can't use hash_to_hex()
> > here. In practice we'd probably not be running sha1 at all if it isn't
> > the current algorithm, but it's possible we might still occasionally
> > need to compute a sha1 in a post-sha256 world.
>
> This second one is OK, but not entirely necessary:
>
> > @@ cache.h: int hex_to_bytes(unsigned char *binary, const char *hex, size_t len);
> > * buffers, making it safe to make multiple calls for a single statement, like:
> > *
> > - * printf("%s -> %s", sha1_to_hex(one), sha1_to_hex(two));
> > -+ * printf("%s -> %s", oid_to_hex(one), oid_to_hex(two));
> > ++ * printf("%s -> %s", hash_to_hex(one), hash_to_hex(two));
> > */
> > char *hash_to_hex_algop_r(char *buffer, const unsigned char *hash, const struct git_hash_algo *);
> > char *oid_to_hex_r(char *out, const struct object_id *oid);
>
> This one-liner leaves the types of "one" and "two" unspecified. :) So
> it's not wrong to use hash_to_hex(), but maybe it's better to be pushing
> people towards oid_to_hex() as their first choice? It probably doesn't
> matter too much either way.
Yeah, most (over 96%) of the hashes that we print are actually object
ids, so oid_to_hex() is the right function to use most of the time.
And because of this the updated "since everybody uses hash_to_hex()"
in the first hunk sounds a bit wrong, because barely anybody actually
uses hash_to_hex().
next prev parent reply other threads:[~2019-11-12 11:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-11 9:03 [PATCH 0/2] getting rid of sha1_to_hex() Jeff King
2019-11-11 9:04 ` [PATCH 1/2] hex: drop sha1_to_hex_r() Jeff King
2019-11-11 18:30 ` Johannes Schindelin
2019-11-11 9:04 ` [PATCH 2/2] hex: drop sha1_to_hex() Jeff King
2019-11-11 14:18 ` SZEDER Gábor
2019-11-11 14:29 ` Jeff King
2019-11-12 4:13 ` Junio C Hamano
2019-11-12 10:57 ` Jeff King
2019-11-12 11:44 ` SZEDER Gábor [this message]
2019-11-12 12:12 ` Jeff King
2019-11-12 11:49 ` Junio C Hamano
2019-11-12 12:15 ` Jeff King
2019-11-13 1:09 ` Junio C Hamano
2019-11-13 1:15 ` Jeff King
2019-11-11 9:09 ` [PATCH 0/2] getting rid of sha1_to_hex() Junio C Hamano
2019-11-11 9:21 ` Jeff King
2019-11-11 23:53 ` brian m. carlson
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=20191112114458.GP4348@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.