git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Design of multiple hash support

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 5, 2018, 02:36 UTC
Message-ID
<xmqqlg68jlny.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<20181105010032.GN731755@genre.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 18 quoted lines
> I'm currently working on getting Git to support multiple hash algorithms
> in the same binary (SHA-1 and SHA-256).  In order to have a fully
> functional binary, we'll need to have some way of indicating to certain
> commands (such as init and show-index) that they should assume a certain
> hash algorithm.
>
> There are basically two approaches I can take.  The first is to provide
> each command that needs to learn about this with its own --hash
> argument.  So we'd have:
>
>   git init --hash=sha256
>   git show-index --hash=sha256 <some-file
>
> The other alternative is that we provide a global option to git, which
> is parsed by all programs, like so:
>
>   git --hash=sha256 init
>   git --hash=sha256 show-index <some-file

I am assuming that "show-index" above is a typo for something like "hash-object"?

It is hard to answer the question without knowing what exactly does "(to) support multiple hash algorithms" mean. For example, inside today's repository, what should this command do?

	git --hash=sha256 cat-file commit HEAD
It can work this way:
 - read HEAD, discover that I am on 'master' branch, read refs/heads/master
   to learn the object name in 40-hex, realize that it cannot be
   sha256 and report "corrupt ref".
Or it can work this way:
 - read repository format, realize it is a good old sha1 repository.
 - do the usual thing to get to read_object() to read the commit
   object data for the commit at HEAD, doing all of it in sha1.
 - in the commit object data, locate references to other objects
   that use sha1 name.
 - replace these sha1 references with their sha256 counterparts and
   show the result.

I am guessing that you are doing the former as a good first step, in which case, as an option that changes/affects the behaviour of git globally, I think "git --hash=sha256" would make sense, like other global options like --literal-pathspecs and --no-replace-objects.

Thanks.
Previous: brian m. carlsonNext: Stefan Beller
Message 2 of 7 in “Design of multiple hash support”
  1. brian m. carlsonNov 5, 2018
  2. Junio C HamanoNov 5, 2018
  3. Stefan BellerNov 5, 2018
  4. brian m. carlsonNov 5, 2018
  5. Duy NguyenNov 5, 2018
  6. Jonathan NiederNov 5, 2018
  7. brian m. carlsonNov 6, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.