Documentation: mark `--object-format=sha256` as experimental

After eff45daab8 ("repository: enable SHA-256 support by default",
2020-07-29), vanilla builds of Git enable the user to run, e.g.,

  git init --object-format=sha256

and hack away. This can be a good way to gain experience with the
SHA-256 world, e.g., to find bugs that

  GIT_TEST_DEFAULT_HASH=sha256 make test

doesn't spot.

But it really is a separate world: Such SHA-256 repos will live entirely
separate from the (by now fairly large) set of SHA-1 repos. Interacting
across the border is possible in principle, e.g., through "diff + apply"
(or "format-patch + am"), but even that has its limitations: Applying a
SHA-256 diff in a SHA-1 repo works in the simple case, but if you need
to resort to `-3`, you're out of luck.

Similarly, "push + pull" should work, but you really will be operating
mostly offset from the rest of the world. That might be ok by the time
you initialize your repository, and it might be ok for several months
after that, but there might come a day when you're starting to regret
your use of `git init --object-format=sha256` and have dug yourself into
a fairly deep hole.

There are currently topics in flight to document our data formats and
protocols regarding SHA-256 and in some cases (midx and commit-graph),
we're considering adjusting how the file formats indicate which object
format to use.

Wherever `--object-format` is mentioned in our documentation, let's make
it clear that using it with "sha256" is experimental. If we later need
to explain why we can't handle data we generated back in 2020, we can
always point to this paragraph we're adding here.

By "include::"-ing a small blurb, we should be able to be consistent
throughout the documentation and can eventually gradually tone down the
severity of this text. One day, we might even use it to start phasing
out `--object-format=sha1`, but let's not get ahead of ourselves...

There's also `extensions.objectFormat`, but it's only mentioned three
times. Twice where we're adding this new disclaimer and in the third
spot we already have a "do not edit" warning. From there, interested
readers should eventually find this new one that we're adding here.

Because `GIT_DEFAULT_HASH` provides another entry point to this
functionality, document the experimental nature of it too.

Signed-off-by: Martin Ågren <>
Signed-off-by: Junio C Hamano <>
Martin Ågren 2020-08-16 12:01:18 +02:00 committed by Junio C Hamano
parent dc04167d37
commit ff233d8dda
5 changed files with 14 additions and 1 deletions

View File

@ -100,6 +100,8 @@ OPTIONS
value is set or outside a repository.
This option cannot be used with --stdin.

View File

@ -53,6 +53,8 @@ current working directory.
Specify the given object format (hash algorithm) for the repository. The valid
values are 'sha1' and (if enabled) 'sha256'. 'sha1' is the default.

View File

@ -44,6 +44,8 @@ OPTIONS
valid values are 'sha1' and (if enabled) 'sha256'. The default is the
algorithm for the current repository (set by `extensions.objectFormat`), or
'sha1' if no value is set or outside a repository..

View File

@ -497,7 +497,8 @@ double-quotes and respecting backslash escapes. E.g., the value
If this variable is set, the default hash algorithm for new
repositories will be set to this value. This value is currently
ignored when cloning; the setting of the remote repository
is used instead. The default is "sha1".
is used instead. The default is "sha1". THIS VARIABLE IS
EXPERIMENTAL! See `--object-format` in linkgit:git-init[1].
Git Commits

View File

@ -0,0 +1,6 @@
THIS OPTION IS EXPERIMENTAL! SHA-256 support is experimental and still
in an early stage. A SHA-256 repository will in general not be able to
share work with "regular" SHA-1 repositories. It should be assumed
that, e.g., Git internal file formats in relation to SHA-256
repositories may change in backwards-incompatible ways. Only use
`--object-format=sha256` for testing purposes.