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

From: David Turner <dturner@twopensource.com>
Date: Jul 28, 2015, 19:54 UTC
Message-ID: <1438113266.18134.26.camel@twopensource.com>
In-Reply-To: <xmqqa8ugdpu7.fsf@gitster.dls.corp.google.com>

On Tue, 2015-07-28 at 12:50 -0700, Junio C Hamano wrote:

Show 12 quoted lines

> David Turner <dturner@twopensource.com> 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.