doc: GIT_DEFAULT_HASH is and will be ignored during "clone"
commit5f0e37b4c1b2acde0d102a5d53766894771457f8
authorJunio C Hamano <gitster@pobox.com>
Wed, 26 Apr 2023 15:13:55 +0000 (26 08:13 -0700)
committerJunio C Hamano <gitster@pobox.com>
Wed, 26 Apr 2023 15:17:04 +0000 (26 08:17 -0700)
tree0b18205d7c938e5d9fb34f6c7fa434a31b88d7e3
parentec583449067bab5b800ecc63926f35c9dae96fa1
doc: GIT_DEFAULT_HASH is and will be ignored during "clone"

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>
Documentation/git.txt