Phillip Wood [off-list ref] writes:

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.