Skip to content

Commit 19d5bb5

Browse files
Martin Ågrengitster
authored andcommitted
Documentation: mark --object-format=sha256 as experimental
After eff45da ("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. Workflows aside, let's consider a more technical aspect. Pack index files (pack-*.idx) exist in two flavours: v1 and v2. The hash transition document foresees a v3, which we do not yet support (and for all we know, the final v3 might end up different from the one sketched in the hash transition document). When the test suite is run with SHA-1 as the default hash algo, it creates and consumes v2 pack files. But with SHA-256, we use an undocumented, hybrid format where the header looks like v2, but where the payload is not only "not correct SHA1", but where even the data sizes are different. The trailing checksum is different, meaning no-one (except us!) should/would try to interpret this file as a proper v2 pack index. We could certainly (re)define v2 to match our SHA-256 behavior, but we do foresee v3 for a reason. And that would still just fix this specific issue. And even when everything around SHA-256 is well-defined and we have SHA-1--SHA-256 interoperability, there's a risk, at least initially, that somewhere we'd be permeating buggy data that we'd then feel responsible for and need to be able to handle for a long time to come. In short: we need some time and leeway. 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 <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent dc04167 commit 19d5bb5

File tree

5 files changed

+14
-1
lines changed

5 files changed

+14
-1
lines changed

Documentation/git-index-pack.txt

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -100,6 +100,8 @@ OPTIONS
100100
value is set or outside a repository.
101101
+
102102
This option cannot be used with --stdin.
103+
+
104+
include::object-format-disclaimer.txt[]
103105

104106
NOTES
105107
-----

Documentation/git-init.txt

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -53,6 +53,8 @@ current working directory.
5353

5454
Specify the given object format (hash algorithm) for the repository. The valid
5555
values are 'sha1' and (if enabled) 'sha256'. 'sha1' is the default.
56+
+
57+
include::object-format-disclaimer.txt[]
5658

5759
--template=<template_directory>::
5860

Documentation/git-show-index.txt

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -44,6 +44,8 @@ OPTIONS
4444
valid values are 'sha1' and (if enabled) 'sha256'. The default is the
4545
algorithm for the current repository (set by `extensions.objectFormat`), or
4646
'sha1' if no value is set or outside a repository..
47+
+
48+
include::object-format-disclaimer.txt[]
4749

4850
GIT
4951
---

Documentation/git.txt

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -497,7 +497,8 @@ double-quotes and respecting backslash escapes. E.g., the value
497497
If this variable is set, the default hash algorithm for new
498498
repositories will be set to this value. This value is currently
499499
ignored when cloning; the setting of the remote repository
500-
is used instead. The default is "sha1".
500+
is used instead. The default is "sha1". THIS VARIABLE IS
501+
EXPERIMENTAL! See `--object-format` in linkgit:git-init[1].
501502

502503
Git Commits
503504
~~~~~~~~~~~
Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
THIS OPTION IS EXPERIMENTAL! SHA-256 support is experimental and still
2+
in an early stage. A SHA-256 repository will in general not be able to
3+
share work with "regular" SHA-1 repositories. It should be assumed
4+
that, e.g., Git internal file formats in relation to SHA-256
5+
repositories may change in backwards-incompatible ways. Only use
6+
`--object-format=sha256` for testing purposes.

0 commit comments

Comments
 (0)