git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 28, 2015, 19:50 UTC
Message-ID
<xmqqa8ugdpu7.fsf@gitster.dls.corp.google.com>
In-Reply-To
<1438111840-6403-1-git-send-email-dturner@twopensource.com>
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?

Previous: David TurnerNext: David Turner
Message 2 of 10 in “cache-tree: populate cache-tree on successful merge”
  1. cache-tree: populate cache-tree on successful mergeDavid Turner, Jul 28, 2015
  2. Junio C HamanoJul 28, 2015
  3. David TurnerJul 28, 2015
  4. Junio C HamanoJul 28, 2015
  5. Junio C HamanoJul 28, 2015
  6. David TurnerJul 28, 2015
  7. Junio C HamanoJul 28, 2015
  8. Junio C HamanoJul 28, 2015
  9. David TurnerJul 28, 2015
  10. Junio C HamanoJul 28, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.