I'm doing some testing on a large Git repository and am finding local clones to take a very long time. After some investigation I've determined that the problem is due to a very large number of tags (~38k). Even with hard links, it just takes a really long time to visit that many inodes. As it happens, I don't care for most of these tags and will prune many of them anyway but I expect that over time it will creep back up again. Have others reported this problem before and is there a workaround? Perhaps Git should switch to a single-file block text or binary format once a large number of tags becomes present in a repository.
Andreas SchwabRe: tag storage format
Uri Moszkowicz <uri@4refs.com> writes:
> Perhaps Git should switch to a single-file block text or binary format > once a large number of tags becomes present in a repository.
This is what git pack-refs (called by git gc) does (by putting the refs in .git/packed-refs).
Andreas.
-- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: tag storage format
That did the trick - thanks!
On Mon, Oct 22, 2012 at 5:46 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
Show 15 quoted lines
> > Uri Moszkowicz <uri@4refs.com> writes: > > > Perhaps Git should switch to a single-file block text or binary format > > once a large number of tags becomes present in a repository. > > This is what git pack-refs (called by git gc) does (by putting the refs > in .git/packed-refs). > > Andreas. > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different."