On Wed, Jul 25, 2018 at 10:56 PM Ben Peart <peartben@xxxxxxxxx> wrote: > > > > On 7/24/2018 11:33 AM, Duy Nguyen wrote: > > On Tue, Jul 24, 2018 at 6:20 AM Jeff King <peff@xxxxxxxx> wrote: > >> At least that's my view of it. unpack_trees() has always been a > >> terrifying beast that I've avoided looking too closely at. > > > > /me nods on the terrifying part. > > > >>> After a quick look at the code, the only place I can find that tries to use > >>> cache_tree_matches_traversal() is in unpack_callback() and that only happens > >>> if n == 1 and in the "git checkout" case, n == 2. Am I missing something? > > > > So we do not actually use cache-tree? Big optimization opportunity (if > > we can make it!). > > > > I agree! Assuming we can figure out the technical issues around using > the cache tree to optimize two way merges, another question I'm trying > to answer is how we can enable this optimization without causing back > compat issues? If it works as I expect, then there's no compat issues at all (exactly like the diff_index_cached optimization we already have). We simply find a safe shortcut that does not add any side effects. -- Duy
