Victoria Dye <vdye@xxxxxxxxxx> writes:
> Shuqi Liang wrote:
>> Update 'git write-tree' to allow using the sparse-index in memory
>> without expanding to a full one.
>>
>> The recursive algorithm for update_one() was already updated in 2de37c5
>> (cache-tree: integrate with sparse directory entries, 2021-03-03) to
>> handle sparse directory entries in the index. Hence we can just set the
>> requires-full-index to false for "write-tree".
>>
>> The `p2000` tests demonstrate a ~96% execution time reduction for 'git
>> write-tree' using a sparse index:
>>
>> Test before after
>> -----------------------------------------------------------------
>> 2000.78: git write-tree (full-v3) 0.34 0.33 -2.9%
>> 2000.79: git write-tree (full-v4) 0.32 0.30 -6.3%
>> 2000.80: git write-tree (sparse-v3) 0.47 0.02 -95.8%
>> 2000.81: git write-tree (sparse-v4) 0.45 0.02 -95.6%
>>
>> Signed-off-by: Shuqi Liang <cheskaqiqi@xxxxxxxxx>
>> ---
>>
>> * change the position of "settings.command_requires_full_index = 0"
>
> Could you describe why you made this change? You don't need to re-roll, but
> in the future please make sure to describe the reasoning for changes like
> this in these version notes if the context can't be gathered from other
> discussions in the thread.
The reason, I think, is because previous iteration hit a BUG() when
the command "git write-tree -h" is run outside a repository. That
form of the help request is handled in the parse_options() machinery
without any need to have a repository or a working tree.
But prepare_repo_settings() does need to be run inside a repository,
so calling it without first checking if we are even in a repository
is asking for trouble.
I guess an alternative fix could have been to see if we are indeed
in a repository, by doing something like
if (the_repository->gitdir) {
prepare_repo_settings(the_repository);
the_repository->settings.command_requires_full_index = 0;
}
like implementations of some subcommands do. And being explicit
that way, instead of relying on an implicit safety given by ordering
of calls, would be more maintainable in the longer haul.
