Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
> In the case of --mixed and --hard, we throw away the old index and
> rebuild everything from the tree argument (or HEAD). So we have an
> opportunity here to fill in the cache-tree data, just as read-tree
> did.
>
> Signed-off-by: Thomas Rast <trast@xxxxxxxxxxxxxxx>
> ---
> builtin/reset.c | 7 +++++++
> t/t0090-cache-tree.sh | 4 ++--
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/reset.c b/builtin/reset.c
> index 811e8e2..8c2c1d5 100644
> --- a/builtin/reset.c
> +++ b/builtin/reset.c
> @@ -43,6 +43,7 @@ static int reset_index_file(const unsigned char *sha1, int reset_type, int quiet
> int nr = 1;
> int newfd;
> struct tree_desc desc[2];
> + struct tree *tree;
> struct unpack_trees_options opts;
> struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
>
> @@ -84,6 +85,12 @@ static int reset_index_file(const unsigned char *sha1, int reset_type, int quiet
> return error(_("Failed to find tree of %s."), sha1_to_hex(sha1));
> if (unpack_trees(nr, desc, &opts))
> return -1;
> +
> + if (reset_type == MIXED || reset_type == HARD) {
> + tree = parse_tree_indirect(sha1);
> + prime_cache_tree(&active_cache_tree, tree);
> + }
The basic idea that MIXED or HARD should result in a cache-tree that match
the tree we just read is sound, but how expensive is prime_cache_tree()? I
think it reads the same tree once again. Admittedly, the data needed to
reconstruct the tree is likely to be hot in core, but it may be necessary
to measure before deciding if this is a good change.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html