On Wed, Aug 3, 2011 at 11:47 AM, Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote: > Hi there, > > On 2011-08-03 at 11:52:33 [+0200], Brecht Machiels <brecht@xxxxxxxxxxx> > wrote: > > On Wed, 03 Aug 2011 11:34:54 +0200, Niels Sascha Reedijk > > <niels.reedijk@xxxxxxxxx> wrote: > > > > >> Yes, that would be great. There's a problem, though. The 40k+ tags do > > >> cause Opera to hang on loading the current GitHub Haiku mirror > > >> (https://github.com/haiku/haiku). Chrome and Firefox don't choke, but > > >> take quite some time for opening the tags list, enough to be very > > >> annoying. I don't know how Web+ handles things. Also, remember that > the > > >> tags make bash completion unusable for the git command line tools. > > > > > > I believe the response to that is 'file a bug report.' > > > > Be my guest. I'd be interested to hear the response :) > > I already filed a ticket at end of June, yielding the following > correspondence: > > --- 8< ----------- 8< ----------- 8< ----------- 8< ----------- 8< ---- > > Github> I am afraid this is a huge number of tags. I can discuss this with > Github> the team, but I cannot promise anything. > > me> I can perfectly understand that adjusting the taglist view to support > me> that many tags would be a considerable amount of work. > me> What would help us tremendously already, is if we would be able to > me> switch off the display of lightweight (i.e. non-annotated) tags > me> somewhere in the repository settings UI. > me> Do you think that has a chance of getting implemented? > > Github> Out of curiosity and if you don't mind, why do you have so many > Github> tags? > Github> I don't think we would ever implement it as an option in the > Github> repository Admin page. We try to minimize the number of options > Github> generally. > Github> To be honest that is a huge number of tags. > > me> we have so many tags since we are/have been moving from subversion to > me> git and (after rather long discussions) decided to stick with having > me> monotically increasing revision numbers in our central repository (and > me> in cloned repos, too). We implement those numbers via leightweight > tags. > me> Git used to be getting slow with many tags, but now offers 'pack-refs' > me> to collect all tags in a single file, which results in decent > me> performance again. While you may certainly question this decision, it > is > me> so firm that it actually led us to choose Git over Mercurial (which was > me> favoured by most of our developers otherwise). > me> I personally think it is a bit unfortunate that git itself does support > me> our chosen workflow and just Github's UI doesn't, because of a specific > me> implementation limitation. > me> The UI aside, is there a way to invoke 'git pack-refs' on the Github > me> repository once in a while after having pushed changesets? Or does > me> Github do regular GCs on hosted git repositories (which, IIRC, as a > me> side-effect packs refs, too)? > > Github> We regularly GC, which should pack the refs from time to time. > > --- 8< ----------- 8< ----------- 8< ----------- 8< ----------- 8< ---- > > Clearly, they don't show much intent to fix the problem. > > cheers, > Oliver > > gitx on Mac OS X also chokes on the 40k tags. It takes around ~20 minutes to start the app and parse the tags. Obviously it is not a very common scenario to have that many tags. I would love to hear a solution. Thank you, John Scipione