On Tue, 2015-07-28 at 12:50 -0700, Junio C Hamano wrote: > David Turner <dturner@xxxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html