Re: [PATCH v4 4/4] blame: enable and test the sparse index
From: Junio C Hamano <hidden>
Date: 2021-11-23 23:54:11
"Lessley Dennington via GitGitGadget" [off-list ref] writes:
quoted hunk
diff --git a/builtin/blame.c b/builtin/blame.c index 641523ff9af..247b9eaf88f 100644 --- a/builtin/blame.c +++ b/builtin/blame.c@@ -902,6 +902,11 @@ int cmd_blame(int argc, const char **argv, const char *prefix) long anchor; const int hexsz = the_hash_algo->hexsz; + if (startup_info->have_repository) {
The command is marked with RUN_SETUP bit in git.c::commands[] list, so I would think we wouldn't even get called if we are not in a repository here. Under what condition can startup_info->have_repository be false at this point in the control flow? If there is such a case, it would mean that startup_info->have_repository bit can be false even if we are in a repository. That sounds like a bug in some code (I do not know where offhand) that is supposed to prepare the startup_info before cmd_X() functions are called.
quoted hunk
diff --git a/t/perf/p2000-sparse-operations.sh b/t/perf/p2000-sparse-operations.sh index 5cf94627383..9ac76a049b8 100755 --- a/t/perf/p2000-sparse-operations.sh +++ b/t/perf/p2000-sparse-operations.sh@@ -114,6 +114,8 @@ test_perf_on_all git reset test_perf_on_all git reset --hard test_perf_on_all git reset -- does-not-exist test_perf_on_all git diff -test_perf_on_all git diff --cached +test_perf_on_all git diff --staged
That's a funny revert of what the previous step did; I thought this step was about "blame" and not "diff".
+test_perf_on_all git blame $SPARSE_CONE/a +test_perf_on_all git blame $SPARSE_CONE/f3/a test_done -# TODO: blame currently does not support blaming files outside of the -# sparse definition. It complains that the file doesn't exist locally. -test_expect_failure 'blame with pathspec outside sparse definition' ' +# NEEDSWORK: This test documents the current behavior, but this could +# change in the future if we decide to support blaming files outside +# the sparse definition.
OK. From the description it is clear that we do not support it right now, which is OK by me.