aboutsummaryrefslogtreecommitdiffstats
path: root/t/helper/test-submodule-nested-repo-config.c
diff options
context:
space:
mode:
authorJunio C Hamano <gitster@pobox.com>2023-04-26 08:13:55 -0700
committerJunio C Hamano <gitster@pobox.com>2023-04-26 08:17:04 -0700
commit5f0e37b4c1b2acde0d102a5d53766894771457f8 (patch)
tree0b18205d7c938e5d9fb34f6c7fa434a31b88d7e3 /t/helper/test-submodule-nested-repo-config.c
parentGit 2.38.5 (diff)
downloadgit-5f0e37b4c1b2acde0d102a5d53766894771457f8.tar.gz
git-5f0e37b4c1b2acde0d102a5d53766894771457f8.zip
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>
Diffstat (limited to 't/helper/test-submodule-nested-repo-config.c')
0 files changed, 0 insertions, 0 deletions