Phillip Wood <phillip.wood123@xxxxxxxxx> 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.
