Phillip Wood wrote: > Hi Victoria > > On 10/11/2022 01:57, Victoria Dye via GitGitGadget wrote: >> Signed-off-by: Victoria Dye <vdye@xxxxxxxxxx> >> --- >> 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.
