Re: [PATCH 4/4] features: feature.manyFiles implies fast index writes
- From
Derrick Stolee <derrickstolee@github.com>
- Date
- Dec 12, 2022, 14:18 UTC
- Message-ID
- <1b2aa60c-633f-0a7f-e8e3-5d0f01ff94b6@github.com>
- In-Reply-To
- <221207.86v8mm972z.gmgdl@evledraar.gmail.com>
On 12/7/2022 5:30 PM, Ævar Arnfjörð Bjarmason wrote:
Show 37 quoted lines
>
> On Wed, Dec 07 2022, Derrick Stolee via GitGitGadget wrote:
>
>> From: Derrick Stolee <derrickstolee@github.com>
>> [...]
>> diff --git a/read-cache.c b/read-cache.c
>> index fb4d6fb6387..1844953fba7 100644
>> --- a/read-cache.c
>> +++ b/read-cache.c
>> @@ -2923,12 +2923,13 @@ static int do_write_index(struct index_state *istate, struct tempfile *tempfile,
>> int ieot_entries = 1;
>> struct index_entry_offset_table *ieot = NULL;
>> int nr, nr_threads;
>> - int skip_hash;
>>
>> f = hashfd(tempfile->fd, tempfile->filename.buf);
>>
>> - if (!git_config_get_maybe_bool("index.skiphash", &skip_hash))
>> - f->skip_hash = skip_hash;
>> + if (istate->repo) {
>> + prepare_repo_settings(istate->repo);
>> + f->skip_hash = istate->repo->settings.index_skip_hash;
>> + }
>
> Urm, are we ever going to find ourselves in a situation where:
>
> * We have read the settings for the_repository
> * We have an index we're about to write out as our "main index", but
> the istate->repo *isn't* the_repository.
> * Even then, wouldn't the two copies of the repos have read the same
> repo settings?
>
> But maybe there's a really obvious submodule / worktree / whatever edge
> case I'm missing.
>
> But if not, shouldn't we just always read/write this from
> the_repository?I don't understand your concern. We call prepare_repo_settings(istate->repo) just before using these settings, so we are using whatever repository-local config we have available to us.
If you're thinking that we could be writing an index but istate->repo is somehow the "wrong" repo, then that is a larger problem. This patch is doing the best thing it can with the information it is given.
Show 9 quoted lines
>> + rm -f .git/index && >> + git -c feature.manyFiles=true \ >> + -c index.skipHash=false add a && >> + test_trailing_hash .git/index >hash && >> + ! test_cmp expect hash > > We had a parallel thread where we discussed "! test_cmp" being an > anti-pattern, i.e. you want them not to be the same, but you want it to > still show a diff, Maybe just "! cmp" ?
I couldn't tell from this sentence whether test_cmp or cmp would show the diff, but from testing I see that test_cmp shows the diff (for debugging purposes, I'm sure) while cmp shows the position of the first difference.
"! cmp" would work here, since we don't care about what the real hash is.
Show 5 quoted lines
> I.e. either the diff will be meaningless, or we really should be > asserting the actual value we want, not what it shouldn't be. > > so in this case, shouldn't we assert that it's the 0000... value, or the > actual hash (depending on which way around we're testing this)?
When it should be the null hash, we assert that it is that value.
When it isn't, we do not assert the exact hash because we do not want other modifications to the index (or surrounding tests) to cause that hash to change, causing toil for future contributors. "! cmp" suffices for this case to show that the config inheritance is working correctly.
Thanks, -Stolee