From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Fri, 17 Jan 2014 14:58:32 +0100 Subject: owner links? (was: author/committer/tagger links -- kernel.org?) In-Reply-To: References: <44979A07-365E-461B-90C4-11B3A23B2683@gmail.com> Message-ID: On Fri, Jan 17, 2014 at 7:58 AM, Kyle J. McKay 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.