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

Re: [RFC] Faster git grep.

From
Ondřej Bílka <neleai@seznam.cz>
Date
Jul 26, 2013, 05:45 UTC
Message-ID
<20130726054550.GA23320@domone.kolej.mff.cuni.cz>
In-Reply-To
<7vhafi3y99.fsf@alter.siamese.dyndns.org>
On Thu, Jul 25, 2013 at 06:28:50PM -0700, Junio C Hamano wrote:
Show 9 quoted lines
> Ondřej Bílka <neleai@seznam.cz> writes:
> 
> > If grepping random commit in history is important use case then keeping
> > db information in history makes sense. Otherwise just having database
> > for current version and updating it on the fly as version changes is
> > enough.
> 
> Will you reindex every time I do "git checkout next; git checkout
> master"?

This is separate issue as you would need to change index anyway, number of changes would be proportionate to size of diff so you would not gain much. Possible problem here is that you would end changing many files. A possible solution is do rebuilding in background.

For switching often to different branches that are vastly different a best solution for me seems to keep separate index for each branch.

Also data structure is trigraph: list of files with counts.
Previous: Junio C Hamano
Message 6 of 6 in “[RFC] Faster git grep.”
  1. Ondřej BílkaJul 25, 2013
  2. Jeff KingJul 25, 2013
  3. Junio C HamanoJul 25, 2013
  4. Ondřej BílkaJul 25, 2013
  5. Junio C HamanoJul 26, 2013
  6. Ondřej BílkaJul 26, 2013

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.