develooper Front page | perl.perl5.porters | Postings from November 2019

Re: smoke-me branches, github, travis - wanting it all...

Thread Previous | Thread Next
Todd Rinaldo
November 18, 2019 17:21
Re: smoke-me branches, github, travis - wanting it all...
Message ID:

> On Nov 7, 2019, at 10:44 PM, Craig A. Berry <> wrote:
> On Wed, Nov 6, 2019 at 8:18 AM Nicholas Clark <> wrote:
>> So how are things supposed to be done?
>> and more generally - getting the most out of github, without getting
>> railroaded by defaults and features that don't fit what we need
> My current pet peeve is that there is no replacement for the  "git
> blame" interface of standard gitweb.  Try to do any blame view in
> GitHub on any file more than a few hundred lines long and you'll get a
> great big angry unicorn icon and a message that says, "This page is
> taking way too long to load. Sorry about that. Please try refreshing
> and contact us if the problem persists."  I don't know what metrics
> they are using exactly, but whether it's number of lines in the file
> or number of commits on the file, it gives up way too easily and hangs
> up on you in a fraction of a second.  There seems to have been an
> explicit decision made that making a version control system show
> versions is too expensive and one shouldn't ask for it.
> I know we had no choice, really, and that BitBucket or GitLab or
> SourceForge or whatever would have had various different and possibly
> worse problems. But not being able to do archive diving for a
> long-running project with large source files is a major defect in
> GitHub, and is something that standard gitweb does quite handily out
> of the box.  I spent an hour a week or two ago trying to teach myself
> how to do git blame with line ranges from the command line and it
> didn't go well.  Is there any chance we could get
> to be a reasonably up-to-date
> mirror?  If so, then all of the things GitHub doesn't do would be less
> of a problem.


I opened a case ( <>) to address this issue. I have an open channel to github and they are monitoring our migration project ( <>). They might be able to address our issue so I've made sure it's included there. Any additional details you can give will help.

As for the backup mirror, I'm a month out and I've still not been able to get the original primary mirror reversed. I think <> (currently a digital ocean droplet) is probably going to become the backup mirror. I'm trying to get the A record moved for the original repo at which point this might solve some issues at least temporarily.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About