develooper Front page | perl.perl5.porters | Postings from August 2012

Re: Testing gitalist for

Thread Previous | Thread Next
Nicholas Clark
August 1, 2012 08:01
Re: Testing gitalist for
Message ID:
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
> 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:

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? )

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

		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:



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

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

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