[haiku-development] Re: Haiku git migration status?

  • From: John Scipione <jscipione@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 3 Aug 2011 12:06:19 -0400

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

Other related posts: