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

Re: Design of multiple hash support

From
Duy Nguyen <pclouds@gmail.com>
Date
Nov 5, 2018, 19:03 UTC
Message-ID
<CACsJy8B+WAyjrthKs9nr=kLpx7f8k_Dug4rRdYDoBR+mmLHCuQ@mail.gmail.com>
In-Reply-To
<20181105010032.GN731755@genre.crustytoothpaste.net>

On Mon, Nov 5, 2018 at 2:02 AM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 20 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 suppose this is about the "no repository/standalone" mode, because
 - it's hard to pass global arguments down to builtin commands (we
often have to rely on global variables which are on the way out)
 - global options confuse new people and also harder to reorder (if
you forget it, you have to alt-b all the way back to near the
beginning of the command line and add it there, instead of near the
end)
 - there aren't that many standalone commands
I'm leaning towards "git foo --hash=".
Show 8 quoted lines
> There's also the question of what we want to call the option.  The
> obvious name is --hash, which is intuitive and straightforward.
> However, the transition plan names the config option
> extensions.objectFormat, so --object-format is also a possibility.  If
> we ever decide to support, say, zstd compression instead of zlib, we
> could leverage the same option (say, --object-format=sha256:zstd) and
> avoid the need for an additional option.  This might be planning for a
> future that never occurs, though.

--object-format is less vague than --hash. The downside is it's longer (more to type) but I'm counting on git-completion.bash and the guess that people rarely need to use this option.

-- 
Duy
Previous: brian m. carlsonNext: Jonathan Nieder
Message 5 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.