Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
> Since 3b1d9e04 (eoie: add End of Index Entry (EOIE) extension,
> 2018-10-10) Git defaults to writing the new EOIE section when writing
> out an index file. Usually that is a good thing because it improves
> threaded performance, but when a Git repository is shared with older
> versions of Git, it produces a confusing warning:
>
> $ git status
> ignoring EOIE extension
> HEAD detached at 371ed0defa
> nothing to commit, working tree clean
>
> Let's introduce the new index extension more gently. First we'll roll
> out the new version of Git that understands it, and then once
> sufficiently many users are using such a version, we can flip the
> default to writing it by default.
>
> Introduce a '[index] recordEndOfIndexEntries' configuration variable
> to allow interested users to benefit from this index extension early.
Thanks. I am in principle OK with this approach. In fact, I
suspect that the default may want to be dynamically determined, and
we give this knob to let the users further force their preference.
When no extension that benefits from multi-threading is written, the
default can stay "no" in future versions of Git, for example.
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 41a9ff2b6a..d702379db4 100644
The timing is a bit unfortunate for any topic to touch this file,
and contrib/cocci would not help us in this case X-<.
> diff --git a/read-cache.c b/read-cache.c
> index f3a848d61c..4bfe93c4c2 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -2698,6 +2698,15 @@ void update_index_if_able(struct index_state *istate, struct lock_file *lockfile
> rollback_lock_file(lockfile);
> }
>
> +static int record_eoie(void)
> +{
> + int val;
> +
> + if (!git_config_get_bool("index.recordendofindexentries", &val))
> + return val;
> + return 0;
> +}
Unconditionally defaulting to no in this round is perfectly fine.
Let's make a mental note that this is the place to decide dynamic
default in the future when we want to. It would probably have to
ask around various "extension writing" helpers if they want to have
a say in the outcome (e.g. if there are very many cache entries in
the istate, the entry offset table may want to be written and
otherwise not).
> @@ -2945,7 +2954,7 @@ static int do_write_index(struct index_state *istate, struct tempfile *tempfile,
> * read. Write it out regardless of the strip_extensions parameter as we need it
> * when loading the shared index.
> */
> - if (offset) {
> + if (offset && record_eoie()) {
> struct strbuf sb = STRBUF_INIT;
>
> write_eoie_extension(&sb, &eoie_c, offset);
> diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
> index 2ac47aa0e4..0cbac64e28 100755
> --- a/t/t1700-split-index.sh
> +++ b/t/t1700-split-index.sh
> @@ -25,14 +25,17 @@ test_expect_success 'enable split index' '
> git update-index --split-index &&
> test-tool dump-split-index .git/index >actual &&
> indexversion=$(test-tool index-version <.git/index) &&
> +
> + # NEEDSWORK: Stop hard-coding checksums.
Also let's stop hard-coding the assumption that the new knob is off
by default. Ideally, you'd want to test both cases, right?
Perhaps you'd call "git update-index --split-index" we see in the
precontext twice, with "-c VAR=false" and "-c VAR=true", to prepare
"actual.without-eoie" and "actual.with-eoie", or something like
that?
Thanks.
> if test "$indexversion" = "4"
> then
> - own=3527df833c6c100d3d1d921a9a782d62a8be4b58
> - base=746f7ab2ed44fb839efdfbffcf399d0b113fb4cb
> + own=432ef4b63f32193984f339431fd50ca796493569
> + base=508851a7f0dfa8691e9f69c7f055865389012491
> else
> - own=5e9b60117ece18da410ddecc8b8d43766a0e4204
> - base=4370042739b31cd17a5c5cd6043a77c9a00df113
> + own=8299b0bcd1ac364e5f1d7768efb62fa2da79a339
> + base=39d890139ee5356c7ef572216cebcd27aa41f9df
> fi &&
> +
> cat >expect <<-EOF &&
> own $own
> base $base
