[haiku-development] Re: Haiku git migration status?
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 03 Aug 2011 17:47:57 +0200
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
Other related posts: