Subject: Re: [PATCH] cache-tree: populate cache-tree on successful merge

From: David Turner <[email-masked]>
Date: Tue, 28 Jul 2015 15:54:26 -0400

On Tue, 2015-07-28 at 12:50 -0700, Junio C Hamano wrote:
> David Turner <[email-masked]> writes:
> 
> > When we unpack trees into an existing index, we discard the old index
> > and replace it with the new, merged index.  Ensure that this index has
> > its cache-tree populated.  This will make subsequent git status and
> > commit commands faster.
> 
> Wouldn't it make repeated calls to "git merge" and friends to build
> a long history slower, when the user does not run "git status" in
> between?  E.g. "git cherry-pick -4 $other_topic", where you would
> not even have a chance to run "git status" in the middle.  What do
> the pros-and-cons look like?

I have not benchmarked, but I suspect it would not make those slower.

The work done to produce the cache-tree is work that the commit would
otherwise have to do.  So we're spending extra time in one place to
eliminate that work in a different place.