Re: [PATCH v2 5/5] rebase: use 'skip_cache_tree_update' option

From: Victoria Dye <vdye@github.com>
Date: Nov 10, 2022, 18:19 UTC
Message-ID: <85230269-2473-2c6a-45a3-59b2b2ed4e3b@github.com>
In-Reply-To: <44b0331a-17e5-1528-2249-e89f0bdd6ffb@dunelm.org.uk>

Phillip Wood wrote:

Show 25 quoted lines

> Hi Victoria
> 
> On 10/11/2022 01:57, Victoria Dye via GitGitGadget wrote:
>> Signed-off-by: Victoria Dye <vdye@github.com>
>> ---
>>   reset.c     | 1 +
>>   sequencer.c | 1 +
>>   2 files changed, 2 insertions(+)
>>
>> diff --git a/reset.c b/reset.c
>> index e3383a93343..5ded23611f3 100644
>> --- a/reset.c
>> +++ b/reset.c
>> @@ -128,6 +128,7 @@ int reset_head(struct repository *r, const struct reset_head_opts *opts)
>>       unpack_tree_opts.fn = reset_hard ? oneway_merge : twoway_merge;
>>       unpack_tree_opts.update = 1;
>>       unpack_tree_opts.merge = 1;
>>       unpack_tree_opts.preserve_ignored = 0; /* FIXME: !overwrite_ignore */
>> +     unpack_tree_opts.skip_cache_tree_update = 1;
> 
> I've added an extra context line above to show that we do either a one-way
> or two-way merge - is it safe to skip the cache_tree_update for the
> two-way merge? (I'm afraid I seem to have forgotten everything I learnt
> about prime_cache_tree() and cache_tree_update() when we discussed this
> optimization before).

Yes - 'prime_cache_tree()' is called immediately after 'unpack_trees()' in both the one-way and two-way merge cases. Because 'prime_cache_tree()' unconditionally clears the cache tree and rebuilds it from scratch, repairing the cache tree with 'cache_tree_update()' at the end of 'unpack_trees()' is unnecessary.