owner links? (was: author/committer/tagger links -- kernel.org?)

[Kyle J. McKay]

On Jan 16, 2014, at 14:02, Jason A. Donenfeld wrote:
> On Thu, Jan 16, 2014 at 2:46 PM, Kyle J. McKay <mackyle at gmail.com>  
> wrote:
>> And we use this hook:
>>
>>  $owner_link_hook =
>>    sub { url_path($Girocco::Config::webadmurl).
>>          "/projlist.cgi?name=".md5_hex($_[0]); };
>>
>
> Well, that wound up being totally trivial, and a logical thing to have
> by default anyway:
>
> http://git.zx2c4.com/cgit/commit/?id=a58e6863cfe4f1411fedd556a96d8f8b9bf75761
> You can try it out on: http://git.zx2c4.com/

Nice.  :)

Of course Girocco requires owner names to be email addresses (and if  
you ever want to update your email address and/or list of public ssh  
keys it needs to be an email address that works) so that would expose  
those to scraping by spam bots...

But we can cross that bridge when we come to it.

>> And besides, the cgit display just looks good.
>> I'd like to add support for cgit to girocco [2] as an alternative  
>> to gitweb.
>> When that's sufficiently mature I'd like to deploy it alongside  
>> gitweb on
>> repo for a time and then we can talk about switching.  :)
>
> That'd be very cool to see. What types of things do you see cgit
> needing to facilitate this?

I wouldn't even propose switching until there would be no lost  
functionality, but it would be okay to run side-by-side with gitweb  
still as the default without feature parity.

For example, this link [1] shows ALL refs in the repository, not just  
those under refs/heads and refs/tags.  That's not just important for  
mirrored repositories, the "Personal Mob Branches" feature [2] also  
needs it to be able to easily browse those.

GitWeb lets you insert custom links into the top of the page, so you  
can see every Girocco project page has a "graphiclog", "edit" and  
"fork" link (I presume that will be easy and possibly already  
supported by cgit).  Handling the fork display may be a bit tricker in  
cgit (especially perhaps on the projects list page).  And while the  
graphiclog browser is not the prettiest thing to use, it does draw  
graphs that can be much easier to follow than the text-based graphs.   
Compare [3] to [4].  That's not to say that graphiclog doesn't have  
its own issues (it is pretty old and not really maintained).  It would  
be nice to update cgit to draw graphs more like googlecode does (see  
[10] for an example).

I think cgit is also missing blame (see [5] for an example).  The  
project tags would also have to be supported, but will probably be  
easy in comparison to blame.

> I don't know how closely you read the list, but some exciting things
> have been happening the last two weeks.

I have been lurking for a while (since before the list moved to  
zx2c4).  I just haven't got to cgit support yet (send me a round toit  
please [11]).  Now that repo.or.cz has https push support there's just  
a few more things I need to tidy up in Girocco before I can really  
focus on cgit support.  Which reminds me that cgit will need non- 
scheme-escaping links.  What I mean is that if I browse to say "http://git.zx2c4.com/cgit 
" all the links on the returned page are "http:" where as if I browse  
to "https://git.zx2c4.com/cgit" all the links on the page come back as  
"https:" (possibly excluding, of course, non-cgit links such as  
gravitars and so on).  As part of adding https support to Girocco, I  
corrected this so that the returned pages do not contain any links  
that escape the scheme that was used to get there.  It may be that  
cgit already has this, but since "https://git.zx2c4.com/cgit" doesn't  
load for me I can't be sure. ;)

> I too didn't like the idea of
> having to run a shell script everytime I wanted to add a gravatar to
> an email address, but I didn't l like the idea of hard coding the
> logic to do so into cgit itself.

Yes.  Gitweb's ability to include perl snippets as part of the gitweb  
config file is very powerful and Lua brings that to cgit.  I haven't  
looked at the cgit auth stuff (yet) because I don't expect it will be  
applicable to Girocco.

> So I integrated Lua/LuaJIT.

May I suggest adding a LuaJIT mirror (see [6] and [7]) to zx2c4 and  
adding that to the .gitmodules file and making it the default LuaJIT  
implementation built as part of the normal cgit make process?  The  
LuaJIT repository is so small (3.5M) compared to the git repository  
already in .gitmodules (205M) that it does not seem like an issue to  
add it.

And while you're in there, why not make the the URLs in .gitmodules  
relative since zx2c4 is already mirroring git?  That would mean that  
anyone else that mirrors cgit, git and luajit would have their mirrors  
used automatically.  (Blender's main git repo does this in  
their .gitmodules file.)  Not really a big deal, just a suggestion.

The Lua project does not have a public source repository (see [8] and  
[9]) and that reason right there is more than enough to convince me to  
always build cgit with LuaJIT instead of Lua.

--Kyle

P.S. Now stepping down off the soap box that I seemed to find myself  
standing on there at the end of this email. ;)

[1] http://repo.or.cz/w/class-dump.git/refs
[2] http://repo.or.cz/h/mob.html
[3] http://git.zx2c4.com/git/log/
[4] http://repo.or.cz/git-browser/by-commit.html?r=git.git
[5] <http://repo.or.cz/w/cgit.git/blame/a58e6863cfe4f1411fedd556a96d8f8b9bf75761:/ui-repolist.c 
 >
[6] http://luajit.org/download.html
[7] http://luajit.org/git/luajit-2.0.git
[8] http://www.lua.org/faq.html#1.8
[9] http://lua-users.org/lists/lua-l/2008-06/msg00407.html
[10] http://code.google.com/p/git-mirror/source/list
[11] http://bytesdaily.blogspot.com/2011/11/round-tuit.html