Re: [PATCH v3 6/8] reset: make sparse-aware (except --mixed)

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 12, 2021, 19:15 UTC
Message-ID: <xmqqv9222gwh.fsf@gitster.g>
In-Reply-To: <cd62bf13-fdf1-af00-cc25-ef20abcfe152@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 9 quoted lines

> I haven't really thought this through but could we teach
> unpack_trees() to call prime_cache_tree() rather than
> cache_tree_update() when that would be safe? For callers that use
> oneway_merge() merge it should always be safe I think and it might be
> possible to modify twoway_merge() to signal if the final tree in the
> index matches the second one passed to it. We could have a more
> general mechanism for the callback to signal if it is safe to prime
> the tree but I suspect the callers that are using custom callbacks are
> not updating the whole tree.

Before going in any direction, other than doing nothing ;-), we'd need to see how expensive "prime" and "update" are.

Having said that.

 * Your idea is quite beneficial for callers of unpack_trees() as
   they no longer have to decide whether they want to make a
   separate call to "prime".

 * Right now we do not seem to have a codepath that

   (1) populates the index entries from existing trees (not
   necessarily making the index in complete sync with the trees)
   without unpack_trees() and

   (2) does "prime" to fix the cache tree

   but such a codepath may want to do either "prime" or "update", or
   neither.  When it knows that it damages cache-tree so badly, and
   that it is often expected that the user would make many other
   changes to the index before writing it out as a tree, it may
   choose not to do either.

Thanks.