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

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

Thread Previous | Thread Next
Craig A. Berry
November 8, 2019 04:44
Re: smoke-me branches, github, travis - wanting it all...
Message ID:
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.

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