| Message ID | xmqqzg6uvfpo.fsf_-_@gitster.g (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 5f0e37b4c1b2acde0d102a5d53766894771457f8 |
| Headers | show |
| Series | doc: GIT_DEFAULT_HASH is and will be ignored during "clone" | expand |
On 2023-04-26 at 15:13:55, Junio C Hamano wrote: > The phrasing "is currently ignored" was prone to be misinterpreted > as if we were wishing if it were honored. Rephrase it to make it > clear that the experimental variable will be ignored. > > In the longer term, after/when we allow incremental/over-the-wire > migration of the object-format, i.e. cloning from an SHA-1 > repository to create an SHA-256 repository (or vice versa) and > fetching and pushing between them would bidirectionally convert the > object format on the fly, it is likely that we would teach a new > option "--object-format" to "git clone" to say "you would use > whatever object format the origin uses by default, but this time, I > am telling you to use this format on our side, doing on-the-fly > object format conversion as needed". So it is perfectly OK to > ignore the settings of this experimental variable, even after such > an extension happens that makes it necessary for us to have a way to > create a new repository that uses different object format from the > origin repository. I have a different proposal which clarifies when it will and will not be honoured in my series. I think we would want to honour this variable once we have SHA-1 and SHA-256 interop, and can convert on the fly, so I think keeping the "currently" here is a good idea.
diff --git c/Documentation/git.txt w/Documentation/git.txt index 74973d3cc4..54b043899f 100644 --- c/Documentation/git.txt +++ w/Documentation/git.txt @@ -546,9 +546,9 @@ double-quotes and respecting backslash escapes. E.g., the value `GIT_DEFAULT_HASH`:: 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". THIS VARIABLE IS + repositories will be set to this value. This value is + ignored when cloning and the setting of the remote repository + is always used. The default is "sha1". THIS VARIABLE IS EXPERIMENTAL! See `--object-format` in linkgit:git-init[1]. Git Commits
The phrasing "is currently ignored" was prone to be misinterpreted as if we were wishing if it were honored. Rephrase it to make it clear that the experimental variable will be ignored. In the longer term, after/when we allow incremental/over-the-wire migration of the object-format, i.e. cloning from an SHA-1 repository to create an SHA-256 repository (or vice versa) and fetching and pushing between them would bidirectionally convert the object format on the fly, it is likely that we would teach a new option "--object-format" to "git clone" to say "you would use whatever object format the origin uses by default, but this time, I am telling you to use this format on our side, doing on-the-fly object format conversion as needed". So it is perfectly OK to ignore the settings of this experimental variable, even after such an extension happens that makes it necessary for us to have a way to create a new repository that uses different object format from the origin repository. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- * An obvious follow-up to the previous discussion. Documentation/git.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)