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.
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@xxxxxxxxxxxxxxxxxxxx>
---
repository.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
I'm still quite mystified as to why this is working on Linux and not
macOS, but I can only guess that compilers are just very advanced and
have somehow concluded that we would clearly never dereference a NULL
pointer, so they picked the only non-NULL value.
I haven't included a test because I have no way to reproduce the issue.
This patch is the first from a series I'm working on where I do expand
the use of the hash struct and therefore caused a segfault on clone, so
I can imagine what's going on without having a way to prove it affects
this particular case.
If someone with access to macOS can provide a test, I'd be very
grateful.
My apologies for the error and inconvenience.
diff --git a/repository.c b/repository.c
index 998413b8bb..f66fcb1342 100644
--- a/repository.c
+++ b/repository.c
@@ -5,7 +5,7 @@
/* The main repository */
static struct repository the_repo = {
- NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, &the_index, NULL, 0, 0
+ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, &the_index, &hash_algos[GIT_HASH_SHA1], 0, 0
};
struct repository *the_repository = &the_repo;
