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

Phillip Wood wrote:

Hi Victoria

On 10/11/2022 01:57, Victoria Dye via GitGitGadget wrote:

quoted

Signed-off-by: Victoria Dye <redacted>
---
  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.