Mailing List Archive: Perl: porters

Testing gitalist for perl5.git.perl.org

Index | Next | Previous | View Threaded

dennis.kaarsemaker at booking

Jul 30, 2012, 11:04 AM

Post #1 of 11 (128 views)
Permalink

Testing gitalist for perl5.git.perl.org

Hi all,

Quite a while ago I looked at using using Gitalist instead of gitweb for
perl5.git.perl.org. At the time it wasn't really ready, but it's
improved quite a bit. David Morel gave me a Catalyst book and over the
last few days I've implemented most of the missing parts.

Some of the improvements over gitweb (for those of you who already use
Gitalist, many improvements currently sit in branches at
https://github.com/seveas/Gitalist -- Dan will review them when he has
time):

* It's a proper web application, thus easily extendable. For
example, the committer overview was integrated instead of
being a horrible cgi script hack:
http://perl5.git.perl.org:3000/committers
* Syntax highlighting using Syntax::Highlight::Engine::Kate.
Example:
http://perl5.git.perl.org:3000/perl.git/HEAD/blob/overload.c
http://perl5.git.perl.org:3000/perl.git/HEAD/blob/lib%2FAnyDBM_File.pm
* POD (and markdown) rendering:
http://perl5.git.perl.org:3000/perl.git/HEAD/html/pod%2Fperlgit.pod
* Pluggable snapshot generator, reducing the size of our own
hack.
* Cherrymaint could be integrated at some point

You can test it at: http://perl5.git.perl.org:3000/

If you do, please provide feedback here or in #p5p and I'll address it
as soon as I can. There are some known issues:

* This is a test instance, running on Catalyst's internal
testserver. This makes it slower than needed.
* Tree view loads commit info with ajax calls, this is slow,
probably due to the above
* The search is less full-featured than gitweb's, which Yves
improved. This will be fixed :)
* Syntax::Highlight::Engine::Kate is a bit buggy, e.g. in C
code the number 4 renders differently for some reason
* Commit messages in gitweb are links to their commit. In
Gitalist they are not. My initial patch is buggy or tickles a
bug in Git::PurePerl that causes a filedescriptor leak, so
that's been reverted for now.

--
Dennis Kaarsemaker, Systems Architect
Booking.com
Herengracht 597, 1017 CE Amsterdam
Tel external +31 (0) 20 715 3409
Tel internal (7207) 3409

sprout at cpan

Jul 30, 2012, 12:57 PM

Post #2 of 11 (119 views)
Permalink

Re: Testing gitalist for perl5.git.perl.org [In reply to]

Dennis Kaarsemaker wrote:
> If you do, please provide feedback here or in #p5p and I'll address it
> as soon as I can. There are some known issues:

The shortlog is not very short. It takes three times as much space as
gitweb. Going back three hundred commits does not consist of simply
clicking the next link three times, but scrolling down and right and
clicking Other Commits 15 times. Also, the fixed width is annoying.
(The purpose of a big screen is to fit multiple things on the screen,
not for one thing to require a huge window.)

I usually tend to be alone in this. So feel free to ignore me. But
could you leave an instance of gitweb running?

> * Syntax::Highlight::Engine::Kate is a bit buggy,

To put it mildly. See
<http://perl5.git.perl.org:3000/perl.git/HEAD/blob/t/op/write.t>.

dcmertens.perl at gmail

Jul 31, 2012, 11:41 AM

Post #3 of 11 (116 views)
Permalink

Re: Testing gitalist for perl5.git.perl.org [In reply to]

Though I cannot comment on its functionality, I think it looks very nice.

If syntax highlighting continues to give trouble, you might consider giving
Scintilla a shot. azawawi is a big proponent, has made web bindings before,
and might be able to help. I can even look up those web bindings when I'm
not on my phone, if you'd like.

David
On Jul 30, 2012 1:05 PM, "Dennis Kaarsemaker" <
dennis.kaarsemaker [at] booking> wrote:

> Hi all,
>
> Quite a while ago I looked at using using Gitalist instead of gitweb for
> perl5.git.perl.org. At the time it wasn't really ready, but it's
> improved quite a bit. David Morel gave me a Catalyst book and over the
> last few days I've implemented most of the missing parts.
>
> Some of the improvements over gitweb (for those of you who already use
> Gitalist, many improvements currently sit in branches at
> https://github.com/seveas/Gitalist -- Dan will review them when he has
> time):
>
> * It's a proper web application, thus easily extendable. For
> example, the committer overview was integrated instead of
> being a horrible cgi script hack:
> http://perl5.git.perl.org:3000/committers
> * Syntax highlighting using Syntax::Highlight::Engine::Kate.
> Example:
> http://perl5.git.perl.org:3000/perl.git/HEAD/blob/overload.c
> http://perl5.git.perl.org:3000/perl.git/HEAD/blob/lib%2FAnyDBM_File.pm
> * POD (and markdown) rendering:
> http://perl5.git.perl.org:3000/perl.git/HEAD/html/pod%2Fperlgit.pod
> * Pluggable snapshot generator, reducing the size of our own
> hack.
> * Cherrymaint could be integrated at some point
>
> You can test it at: http://perl5.git.perl.org:3000/
>
> If you do, please provide feedback here or in #p5p and I'll address it
> as soon as I can. There are some known issues:
>
> * This is a test instance, running on Catalyst's internal
> testserver. This makes it slower than needed.
> * Tree view loads commit info with ajax calls, this is slow,
> probably due to the above
> * The search is less full-featured than gitweb's, which Yves
> improved. This will be fixed :)
> * Syntax::Highlight::Engine::Kate is a bit buggy, e.g. in C
> code the number 4 renders differently for some reason
> * Commit messages in gitweb are links to their commit. In
> Gitalist they are not. My initial patch is buggy or tickles a
> bug in Git::PurePerl that causes a filedescriptor leak, so
> that's been reverted for now.
>
> --
> Dennis Kaarsemaker, Systems Architect
> Booking.com
> Herengracht 597, 1017 CE Amsterdam
> Tel external +31 (0) 20 715 3409
> Tel internal (7207) 3409
>
>

nick at ccl4

Aug 1, 2012, 8:01 AM

Post #4 of 11 (117 views)
Permalink

Re: Testing gitalist for perl5.git.perl.org [In reply to]

On Mon, Jul 30, 2012 at 08:04:50PM +0200, Dennis Kaarsemaker wrote:

> Quite a while ago I looked at using using Gitalist instead of gitweb for
> perl5.git.perl.org. At the time it wasn't really ready, but it's
> improved quite a bit. David Morel gave me a Catalyst book and over the
> last few days I've implemented most of the missing parts.

Thanks for doing this.

> * POD (and markdown) rendering:
> http://perl5.git.perl.org:3000/perl.git/HEAD/html/pod%2Fperlgit.pod

This is something I've really wanted.

I hope it's also easy to add the option of "ignore whitespace changes"
to the blame view.

There's stuff I'm not that keen on

I find the colour scheme too blunt and in my face. It's distracting me from
the actual content. This may just be because I'm not used to it.

I don't like the tree view having case insensitive ordering, and putting
directories first. That's not how ls does it, and I'm very used thinking
about things in the lexical order ls gives them to me.

("case insensitive" doesn't make me happy, if all it really means is
tr/A-Z/a-z/. And if it doesn't mean that, then it's not a viable long term
proposition for filenames, until Unicode goes special biologist word. ie

A strange game. The only winning move is not to play. How about a nice
game of chess?

http://www.imdb.com/title/tt0086567/quotes?qt0453844 )

I'm not sure that I like having the date and the committer in the blame
view as well as the hash. gitweb provides this with a mouse over, which
I prefer. (It also means that knowing "whodunit" doesn't cloud my
judgement of what I think of the code.) gitweb's use of alternating
background colours *across the source code* to provide boundaries between
commits seems much easier to follow than how gitalist does it.
(No rules across the source code, and colour coding based (I think) on
commit hash.)

Then, unfortunately, there's stuff I really don't like. This is going to
sound ugly, particularly as I think I know several of the gitalist team
quite well socially:

On Mon, Jul 30, 2012 at 07:57:29PM -0000, Father Chrysostomos wrote:

> The shortlog is not very short. It takes three times as much space as
> gitweb. Going back three hundred commits does not consist of simply
> clicking the next link three times, but scrolling down and right and
> clicking Other Commits 15 times. Also, the fixed width is annoying.
> (The purpose of a big screen is to fit multiple things on the screen,
> not for one thing to require a huge window.)
>
> I usually tend to be alone in this. So feel free to ignore me. But
> could you leave an instance of gitweb running?

No you're not alone.

I hate the margin. Why do I have fixed with content floating within a variable
width white margin? Waste of screen space. Can that go?

But worse - gitalist, as is, is a *really* inefficient user of vertical
space:

gitalist gitweb
Shortlog 12 34 gitweb three times more effective
Tree 16 36 gitweb twice as effective
Blame 27 43 gitweb 50% more effective

I can shrink the font for the gitalist shortlog to get 14 on the screen,
before it becomes unreadable. I can't for the other two views above.

(Oh, but it turns out I can shrink the font for gitweb one notch and it's
still easily readable. So that would make the ratios even worse)

The gitlist blame view also has uneven line spacing, for some reason.
That's not good.

I hope that the above are easy to fix with CSS

Also, clicking on the line number in gitweb takes me to the blame view for
the revision with the previous version of that line, aligned at that line.
It doesn't in gitalist. Is that functionality gone? I *need* that.

[URLs for the pages I tested with:
Shortlog:
http://perl5.git.perl.org:3000/perl.git/9fa1f09fe74e63fd5b313c36efc35bb18e73faf3/shortlog
http://perl5.git.perl.org/perl.git/shortlog

Tree
http://perl5.git.perl.org:3000/perl.git/9fa1f09fe74e63fd5b313c36efc35bb18e73faf3/tree
http://perl5.git.perl.org/perl.git/tree/9fa1f09fe74e63fd5b313c36efc35bb18e73faf3

Blame:
http://perl5.git.perl.org:3000/perl.git/9fa1f09fe74e63fd5b313c36efc35bb18e73faf3/blame/gv.c#l1
http://perl5.git.perl.org/perl.git/blame/9fa1f09fe74e63fd5b313c36efc35bb18e73faf3:/gv.c#l1
]

I think there are 4 principal reasons I find the gitweb blame view the most
useful way to navigate history. Most of it is a side effect of web browsers:

1: direct link from each line to the blame view at the same line number for
the parent of the commit at that line (ie the "previous" version)
2: "open in new tab" means that I can "fork" my browsing, and go off in more
than one direction
3: clear "forwards/backwards" navigation
4: URLs provide a way to precisely save the context needed to get to a given
view

gitweb also has a big advantage over git blame in a terminal, in that one
can click to view the relevant commit. I think there's another subtle reason
that I like it, but it eludes me at the moment. I hope hitting "send" will
fix that.

*As is*, the only thing I like more about gitalist is that it can render Pod.
I hope things change.

Nicholas Clark

perl.p5p at rjbs

Aug 1, 2012, 9:14 AM

Post #5 of 11 (116 views)
Permalink

Re: Testing gitalist for perl5.git.perl.org [In reply to]

* Nicholas Clark <nick [at] ccl4> [2012-08-01T11:01:14]
> On Mon, Jul 30, 2012 at 08:04:50PM +0200, Dennis Kaarsemaker wrote:
>
> > Quite a while ago I looked at using using Gitalist instead of gitweb for
> > perl5.git.perl.org. At the time it wasn't really ready, but it's
> > improved quite a bit. David Morel gave me a Catalyst book and over the
> > last few days I've implemented most of the missing parts.
>
> Thanks for doing this.

Yes! I'd love to see us using something better than gitweb.

> I hope it's also easy to add the option of "ignore whitespace changes"
> to the blame view.

That would be sweet.

> There's stuff I'm not that keen on
>
> I find the colour scheme too blunt and in my face. It's distracting me from
> the actual content. This may just be because I'm not used to it.

Doesn't bother me much. I remain ever-grumpy by sites that have a really tall
header, but fine. I can cope.

> On Mon, Jul 30, 2012 at 07:57:29PM -0000, Father Chrysostomos wrote:
>
> > The shortlog is not very short. It takes three times as much space as
> > gitweb. Going back three hundred commits does not consist of simply
> > clicking the next link three times, but scrolling down and right and
> > clicking Other Commits 15 times. Also, the fixed width is annoying.
> > (The purpose of a big screen is to fit multiple things on the screen,
> > not for one thing to require a huge window.)
> >
> > I usually tend to be alone in this. So feel free to ignore me. But
> > could you leave an instance of gitweb running?
>
> No you're not alone.

I think we'd want to keep gitweb running at least for a while, yes.

As for the "not very short," yes, I agree. The number of commits per screenful
is grossly reduced, and it bothers me.

> *As is*, the only thing I like more about gitalist is that it can render Pod.
> I hope things change.

I think there's a lot to be said for the fact that it's almost certainly easier
to hack on than gitweb. Unfortunately, I know I won't be doing any of that
hacking. Unless we know someone will, it's an empty promise for us.

So, who wants to be a dedicated "Gitalist for p5p" hacker?

--
rjbs

Attachments:

signature.asc (0.48 KB)

dennis.kaarsemaker at booking

Aug 1, 2012, 4:48 PM

Post #6 of 11 (117 views)
Permalink

Re: Testing gitalist for perl5.git.perl.org [In reply to]

On ma, 2012-07-30 at 19:57 +0000, Father Chrysostomos wrote:
> Dennis Kaarsemaker wrote:
> > If you do, please provide feedback here or in #p5p and I'll address it
> > as soon as I can. There are some known issues:
>
> The shortlog is not very short. It takes three times as much space as
> gitweb. Going back three hundred commits does not consist of simply
> clicking the next link three times, but scrolling down and right and
> clicking Other Commits 15 times.

Vertical whitespace is something that's on my list to address

> Also, the fixed width is annoying.

Removing the fixed width will help with the vertical whitespace, so it's
on my list too.

> (The purpose of a big screen is to fit multiple things on the screen,
> not for one thing to require a huge window.)
>
> I usually tend to be alone in this. So feel free to ignore me. But
> could you leave an instance of gitweb running?

We're not switching to gitalist anytime soon, there's still too much to
address. And even after that, gitweb can be there as non-default
interface.

> > * Syntax::Highlight::Engine::Kate is a bit buggy,
>
> To put it mildly. See
> <http://perl5.git.perl.org:3000/perl.git/HEAD/blob/t/op/write.t>.

Hmm, formats :)

--
Dennis Kaarsemaker, Systems Architect
Booking.com
Herengracht 597, 1017 CE Amsterdam
Tel external +31 (0) 20 715 3409
Tel internal (7207) 3409

dennis.kaarsemaker at booking

Aug 1, 2012, 4:55 PM

Post #7 of 11 (115 views)
Permalink

Re: Testing gitalist for perl5.git.perl.org [In reply to]

On wo, 2012-08-01 at 16:01 +0100, Nicholas Clark wrote:

> *As is*, the only thing I like more about gitalist is that it can
> render Pod.I hope things change.

Thanks *very much* for taking the time to test and provide such detailed
feedback. It's all on my TODO list now. I'll try to fix most things in a
way that can be upstreamed until Dan gets tired of my pull requests :-)
--
Dennis Kaarsemaker, Systems Architect
Booking.com
Herengracht 597, 1017 CE Amsterdam
Tel external +31 (0) 20 715 3409
Tel internal (7207) 3409

dennis.kaarsemaker at booking

Aug 1, 2012, 5:00 PM

Post #8 of 11 (114 views)
Permalink

Re: Testing gitalist for perl5.git.perl.org [In reply to]

On wo, 2012-08-01 at 12:14 -0400, Ricardo Signes wrote:

> I think we'd want to keep gitweb running at least for a while, yes.

Absoultely.

> I think there's a lot to be said for the fact that it's almost certainly easier
> to hack on than gitweb. Unfortunately, I know I won't be doing any of that
> hacking. Unless we know someone will, it's an empty promise for us.

I think the fact that I was able to hack on it with no prior knowledge
of Moose, Catalyst or the Gitalist codebase proves that point :-)

> So, who wants to be a dedicated "Gitalist for p5p" hacker?

I'll definitely address all the feedback from this thread and #p5p and
want to take a stab at integrating cherrymaint, if you agree with making
a more public read-only interface for it.

--
Dennis Kaarsemaker, Systems Architect
Booking.com
Herengracht 597, 1017 CE Amsterdam
Tel external +31 (0) 20 715 3409
Tel internal (7207) 3409

craig.a.berry at gmail

Aug 1, 2012, 8:45 PM

Post #9 of 11 (117 views)
Permalink

Re: Testing gitalist for perl5.git.perl.org [In reply to]

On Mon, Jul 30, 2012 at 1:04 PM, Dennis Kaarsemaker
<dennis.kaarsemaker [at] booking> wrote:

> You can test it at: http://perl5.git.perl.org:3000/
>
> If you do, please provide feedback here or in #p5p and I'll address it
> as soon as I can. There are some known issues:

This is all very subjective, and since there are lots of other
subjectivities involved I realize the best you can do is compute the
min of the unhappiness function, but here are a few impressions.

I really like the fact that snapshots of arbitrary commits are
available (and they even include the .patch file). I would prefer
.zip to .tar.bz2, but I suspect that's a minority opinion.

The first thing that struck me visually was how gigantic the headers
are. I pulled out a ruler and measured 6 cm from the top of the page
to where it says "Perl5 Master Repository". I think that ought to be
reduced by at least half.

One way of acquiring header real estate would be to ditch the huge
gitalist logo in the upper left corner. A "powered by gitalist" logo
about 1/8 the size of the current logo and down at the bottom of the
page next to the git logo would be appropriate. The oversized
advertisement for gitalist on prime real estate is distracting and
inappropriate.

The headers have 3 lines to them:

gitalist logo / search
branches drop-down / short log / long log / tree
Home / whatever / whatever

I think that ought to be reduced to at most 2 lines. In addition to
getting rid of the logo, I'm not sure the branches drop-down serves
much purpose as the branches are listed in their own section lower
down.

The only problem with colors I have is the color gray, which is
everywhere. Gray text on a white or off-white background requires
much more effort for me to read than black text on a white background.
White text on a gray background, such as in the blob and blame views,
is even worse.

The blame and blob views have fixed widths that are too narrow for
much of the code (gitweb uses the full width of the window, whatever
it happens to be). Yes, there is a horizontal scroll bar at the
bottom, but scrolling all the way to the bottom of the 14,437 lines of
sv.c in order to scroll right, then scrolling back up to wherever I
was is non-workable.

If the performance problems with tree view involve more than just
using the dev version of Catalyst, that's a dealbreaker. gitweb is
pretty darn good, but not quite fast enough for the archive diving I
do. Unless gitalist is noticeably faster than gitweb, switching is
less than compelling.

dennis.kaarsemaker at booking

Aug 2, 2012, 1:04 AM

Post #10 of 11 (116 views)
Permalink

Re: Testing gitalist for perl5.git.perl.org [In reply to]

On wo, 2012-08-01 at 22:45 -0500, Craig A. Berry wrote:

> I really like the fact that snapshots of arbitrary commits are
> available (and they even include the .patch file). I would prefer
> .zip to .tar.bz2, but I suspect that's a minority opinion.

Similar snapshots are available in gitweb too, Yves wrote the code for
that when we moved to git. Gitalist can provide snapshots in
tar.gz/tar.bz2/tar.xz and zip formats by changing the url. I need to
figure out a way of making this available in the ui without overdoing
the number of links.

> The first thing that struck me visually was how gigantic the headers
> are. I pulled out a ruler and measured 6 cm from the top of the page
> to where it says "Perl5 Master Repository". I think that ought to be
> reduced by at least half.

Yeah, gigantic header will go. Everybody complained about vertical
whitespace abuse, so I don't think it coundts as subjective anymore.

> The only problem with colors I have is the color gray, which is
> everywhere. Gray text on a white or off-white background requires
> much more effort for me to read than black text on a white background.
> White text on a gray background, such as in the blob and blame views,
> is even worse.

The blob/blame backround will go, and I'll increase contrast where
needed.

> The blame and blob views have fixed widths that are too narrow for
> much of the code (gitweb uses the full width of the window, whatever
> it happens to be). Yes, there is a horizontal scroll bar at the
> bottom, but scrolling all the way to the bottom of the 14,437 lines of
> sv.c in order to scroll right, then scrolling back up to wherever I
> was is non-workable.

This is also a common complaint and will be fixed.

> If the performance problems with tree view involve more than just
> using the dev version of Catalyst, that's a dealbreaker. gitweb is
> pretty darn good, but not quite fast enough for the archive diving I
> do. Unless gitalist is noticeably faster than gitweb, switching is
> less than compelling.

Yeah, unless the tree view is actually considerably faster, it's pretty
close to useless for any serious work.

--
Dennis Kaarsemaker, Systems Architect
Booking.com
Herengracht 597, 1017 CE Amsterdam
Tel external +31 (0) 20 715 3409
Tel internal (7207) 3409

pagaltzis at gmx

Aug 4, 2012, 2:45 AM

Post #11 of 11 (113 views)
Permalink

Re: Testing gitalist for perl5.git.perl.org [In reply to]

* Craig A. Berry <craig.a.berry [at] gmail> [2012-08-02 05:50]:
> The only problem with colors I have is the color gray, which is
> everywhere. Gray text on a white or off-white background requires much
> more effort for me to read than black text on a white background.
> White text on a gray background, such as in the blob and blame views,
> is even worse.

You don’t want to increase contrast too far either. Very dark grey on
off-white is considerably easier to read than full black on full white.
It’ll be considered “black on white” by most people so this is mostly
technical nitpicking, but the seemingly subtle difference in colour can
be enormous in contrast.

(As an irrelevant aside, it’s been found [1] that dark green on light
yellow is by far the most readable colouring for text.)

[1]: http://www.laurenscharff.com/research/AHNCUR.html

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads