From: Duy Nguyen <pclouds@gmail.com>
Date: Thu, 26 Jul 2018 16:35:19 GMT
Subject: Re: [PATCH v1 0/3] [RFC] Speeding up checkout (and merge, rebase, etc)
Message-ID: <CACsJy8Af4K=XOcGaZxhbWOD7OYgtW7bXLved_Xv-XgVM_6AQwQ@mail.gmail.com>
In-Reply-To: <0102d204-8be7-618a-69f4-9f924c4e6731@gmail.com>

On Wed, Jul 25, 2018 at 10:56 PM Ben Peart <peartben@gmail.com> wrote:
>
>
>
> On 7/24/2018 11:33 AM, Duy Nguyen wrote:
> > On Tue, Jul 24, 2018 at 6:20 AM Jeff King <peff@peff.net> 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