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

Re: Git performance problems with many tags

From
Junio C Hamano <junkio@cox.net>
Date
Mar 26, 2007, 06:13 UTC
Message-ID
<7vwt14zg5o.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<20070326045341.GE10545@ws35.commsecure.com.au>
Tim Allen <tim@commsecure.com.au> writes:
Show 10 quoted lines
> However, operations like 'git-fetch' take much, much longer in our
> repository than in the kernel repository: a git-fetch that pulls no
> updates in the kernel repository takes 1.7s, while our repository
> (fetching from one repository to a clone on the same local disk) takes
> about 20 seconds.
> ...
> Does git have known scalability problems with large numbers of tags? Is
> there anything we can do to mitigate this slowdown, apart from just not
> using git's tag feature at all? Are there any details I've overlooked or
> misunderstood?

An optimization for "fetching between repositories with insane number of refs" problem was merged after v1.5.0, so if you try the current tip of 'master' (which happens to be at v1.5.1-rc2 right now), I suspect you may see significant improvements.

Previous: Shawn O. Pearce
Message 3 of 3 in “Git performance problems with many tags”
  1. Tim AllenMar 26, 2007
  2. Shawn O. PearceMar 26, 2007
  3. Junio C HamanoMar 26, 2007

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.