Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH 02/22] hex: add functions to parse hex object IDs in any algorithm
Date: Thu, 16 Jan 2020 00:22:52 +0000
Message-ID: <20200116002252.GX6570@camp.crustytoothpaste.net> (raw)
In-Reply-To: <xmqqv9pciejd.fsf@gitster-ct.c.googlers.com>

[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]

On 2020-01-15 at 21:40:54, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > +/*
> > + * NOTE: This function relies on hash algorithms being in order from shortest
> > + * length to longest length.
> > + */
> > +int get_oid_hex_any(const char *hex, struct object_id *oid)
> > +{
> > +	int i;
> > +	for (i = GIT_HASH_NALGOS - 1; i > 0; i--) {
> > +		if (!get_hash_hex_algop(hex, oid->hash, &hash_algos[i]))
> > +			return i;
> > +	}
> > +	return GIT_HASH_UNKNOWN;
> > +}
> 
> Two rather obvious questions are
> 
>  - what if we have more than one algos that produce hashes of the
>    same length?

Than we have a problem that we'll have to deal with then.  There are a
handful of functions that essentially document all these locations and
we'll have to decide how we fix them.

Notably, the dumb HTTP protocol doesn't provide any capability
advertisement, so it's not possible to ask the remote server which
algorithm it's using or negotiate a different one.  Bundles and
get-tar-commit-id are the other problem cases.

Granted, I did very much try to limit these cases as much as possible,
and most of our more modern code doesn't have this problem, but in some
cases it's just unavoidable.  I feel like with only three uses, doing
this won't be mortgaging our future too much.

>  - it feels that GIT_HASH_UNKNOWN being 0 wastes the first/zeroth
>    element in the hash_algos[] array.

I actually think it's really useful to have it this way, because then
it's easy to check for a valid hash algorithm by a comparison against 0.

> In the future, I would imagine that we would want to be able to say
> "here I have a dozen hexdigits that is an abbreviated SHA2 hash",
> and we would use some syntax (e.g. "sha2:123456123456") for that.
> Would this function be at the layer that would be extended later to
> support such a syntax, or would we have a layer higher than this to
> do so?

That's going to be at a different layer.  We'll have the ^{sha1} and
^{sha256} disambiguators that can be used with the normal revision
parsing syntax, and we'll handle the ambiguity there if one isn't
provided.  As for output, we'll only produce output in one algorithm at
a time so ambiguity isn't a problem there.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]

  reply index

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-13 12:47 [RFC PATCH 00/22] SHA-256 stage 4 implementation, part 1/3 brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 01/22] hex: introduce parsing variants taking hash algorithms brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 02/22] hex: add functions to parse hex object IDs in any algorithm brian m. carlson
2020-01-15 21:40   ` Junio C Hamano
2020-01-16  0:22     ` brian m. carlson [this message]
2020-01-13 12:47 ` [RFC PATCH 03/22] repository: require a build flag to use SHA-256 brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 04/22] t: use hash-specific lookup tables to define test constants brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 05/22] t6300: abstract away SHA-1-specific constants brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 06/22] t6300: make hash algorithm independent brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 07/22] t/helper/test-dump-split-index: initialize git repository brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 08/22] t/helper: initialize repository if necessary brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 09/22] t/helper: make repository tests hash independent brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 10/22] setup: allow check_repository_format to read repository format brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 11/22] builtin/init-db: allow specifying hash algorithm on command line brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 12/22] builtin/init-db: add environment variable for new repo hash brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 13/22] init-db: move writing repo version into a function brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 14/22] worktree: allow repository version 1 brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 15/22] commit: use expected signature header for SHA-256 brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 16/22] gpg-interface: improve interface for parsing tags brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 17/22] tag: store SHA-256 signatures in a header brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 18/22] fast-import: permit reading multiple marks files brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 19/22] fast-import: add helper function for inserting mark object entries brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 20/22] fast-import: make find_marks work on any mark set brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 21/22] fast-import: add a generic function to iterate over marks brian m. carlson
2020-01-13 12:47 ` [RFC PATCH 22/22] fast-import: add options for rewriting submodules brian m. carlson

Reply instructions:

You may reply publically 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=20200116002252.GX6570@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git