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

Jason A. Donenfeld Jason at zx2c4.com
Fri Jan 17 14:58:32 CET 2014


On Fri, Jan 17, 2014 at 7:58 AM, Kyle J. McKay <mackyle at gmail.com> wrote:
> 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.

enable-remote-branches=1

For investigation into "what about the other refs? how do these work
with cgit?", if you send a well researched separate email for
something like this to the list, I or someone else will have a look at
it in do time.

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

That's very pretty indeed. If you'd like to revamp our graph display,
a patch would be most welcome.

>
> 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.

Blame support would be very nice; I personally would enjoy this
feature. Could you send a [well researched and thought-out] separate
thread about this? (A patch would be nicest, but in lieu of that,
maybe someone else will write it for us...)


> 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. ;)

Whenever we reference a resource by a full host name (which is rare),
we use "//", including for Gravatars, so that they're loaded from the
same scheme as the page. Do you have any indication that we do
otherwise?

>
> 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.

That's not a bad idea. OTOH, LuaJIT and Lua are best installed as
system wide shared libraries, not a static library we link to, as in
the case of libgit.a. Further, LuaJIT doesn't run on all archs. In any
case, starting a new thread for this would make most sense.

> 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.

That's a nice idea. I'll consider updating the git repo in modules to
point to my mirror. I don't see much technical benefit of this, other
than not relying on anyone else's infra to build cgit, which is a
plus.


More information about the CGit mailing list