summaryrefslogtreecommitdiff
path: root/progress.h
diff options
context:
space:
mode:
authorLibravatar brian m. carlson <sandals@crustytoothpaste.net>2018-01-19 04:18:25 +0000
committerLibravatar Junio C Hamano <gitster@pobox.com>2018-01-19 14:23:32 -0800
commite26f7f19b6c7485f04234946a59ab8f4fd21d6d1 (patch)
tree24c24efe1ee935b43f80f79f5d84d210b842dc87 /progress.h
parentrepository: fix a sparse 'using integer as NULL pointer' warning (diff)
downloadtgif-e26f7f19b6c7485f04234946a59ab8f4fd21d6d1.tar.xz
repository: pre-initialize hash algo pointer
There are various git subcommands (among them, clone) which don't set up the repository (that is, they lack RUN_SETUP or RUN_SETUP_GENTLY) but end up needing to have information about the hash algorithm in use. Because the hash algorithm is part of struct repository and it's only initialized in repository setup, we can end up dereferencing a NULL pointer in some cases if we call one of these subcommands and look up the empty blob or empty tree values. A "git clone" of a project that has two paths that differ only in case suffers from this if it is run on a case insensitive platform. When the command attempts to check out one of these two paths after checking out the other one, the checkout codepath needs to see if the version that is already on the filesystem (which should not happen if the FS were case sensitive) is dirty, and it needs to exercise the hashing code at that point. In the future, we can add a command line option for this or read it from the configuration, but until we're ready to expose that functionality to the user, simply initialize the repository structure to use the current hash algorithm, SHA-1. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'progress.h')
0 files changed, 0 insertions, 0 deletions