Re: 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   
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 myse

Re: [RFC] Moving the about tab to the left

[Jason A. Donenfeld]

There were no comments about this after I posted this seven months ago, so
I'm going to merge this, pending no objections.

On May 26, 2013 4:36 PM, "Jason A. Donenfeld"  wrote:
>
> Hello,
>
> I'm considering a cosmetic change that may be controversial.
>
> If the about tab is enabled, then it's been enabled explicitly,
> through use of a config value or by adding a file, and has a nice
> reason for being there. As such, I think it should be the first tab on
> the left. The default tab that's opened will still be 'summary', and
> this tab will still be mapped to the base url, but aesthetically, this
> just moves the about tab to the left of summary. I've made this change
> on  if you'd like to see how it looks.
>
> What do you think?
>
> Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Policy on global variables

[Jason A. Donenfeld]

On Thu, Jan 16, 2014 at 11:20 PM, John Keeping  wrote:
> At once (as in in parallel), or without needing to fork for every
> request?  I think that many requests serially in the same process is a
> much more likely scenario (that's what FastCGI does); in that case all
> we need to do is clean up after each request and it doesn't make much
> difference if that state is global or passed down through the functions
> that need it.

Yea, that's a good point I suppose. Parallel request capability would
still be nice, in some abstract sense, but I guess it's not clear what
the benefits would be practically. I'll merge Lukas' patch, and we'll
refactor later if necessary.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Policy on global variables

[John Keeping]

On Thu, Jan 16, 2014 at 10:36:34PM +0100, Jason A. Donenfeld wrote:
> On Thu, Jan 16, 2014 at 10:34 PM, John Keeping  wrote:
> >
> > I'm not sure it makes much difference either way.  Even if we use
> > libgit2, providing we're not processing more than one request at once we
> > can still use a global cgit_context.
> 
> Well, the idea of moving to libgit2, in the first place, would be to
> benefit from its reentrancy, so that we could process multiple
> requests at once (potentially).

At once (as in in parallel), or without needing to fork for every
request?  I think that many requests serially in the same process is a
much more likely scenario (that's what FastCGI does); in that case all
we need to do is clean up after each request and it doesn't make much
difference if that state is global or passed down through the functions
that need it.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

[PATCH] repolist: make owner clickable to search

[Jason A. Donenfeld]

Signed-off-by: Jason A. Donenfeld 
---

** MAYBE THIS WON'T BE MERGED **

This is super simple and seems like a no brainer but...

As an alternative to this, we could pretty easily pipe the
owner through the "email-filter", even though the owner name isn't
associated with an email address.

What do you guys think is best here?


 ui-repolist.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ui-repolist.c b/ui-repolist.c
index f9cb21a..9a75661 100644
--- a/ui-repolist.c
+++ b/ui-repolist.c
@@ -306,7 +306,13 @@ void cgit_print_repolist()
html_link_close();
html("");
if (ctx.cfg.enable_index_owner) {
+   html("");
html_txt(ctx.repo->owner);
+   html("");
html("");
}
print_modtime(ctx.repo);
-- 
1.8.5.2

___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

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

[Jason A. Donenfeld]

On Thu, Jan 16, 2014 at 2:46 PM, Kyle J. McKay  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/



> Looking at top, gitweb is clearly a CPU pig on repo.or.cz (git clones can
> also be piggy but I expect that to drop significantly when the new pack
> bitmap support is deployed).  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?

> As you can see from the hook text above the repo gitweb hook only offers the
> ability to attach a link, it doesn't actually let one generate the markup or
> change the displayed owner name.  That's all I really need.  On the project
> list page [3] there are thousands of these, so running a shell script for
> each one is a non-starter.  A simple regex is not good enough either because
> it needs to generate the md5 hash (probably ought to be md5_hex(lc($_[0]))
> too -- another TODO item).

I don't know how closely you read the list, but some exciting things
have been happening the last two weeks. 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. So I integrated Lua/LuaJIT. It's
super super fast, only needs to evaluate the script one time (and then
each email it filters reuses the same context), and most importantly,
doesn't need to fork ever. We're using this for the new authentication
framework too:

http://git.zx2c4.com/cgit/tree/cgitrc.5.txt#n578
http://git.zx2c4.com/cgit/tree/filters/email-gravatar.lua
http://git.zx2c4.com/cgit/tree/filters/simple-authentication.lua

So it seems most feasible to use this for email obfuscation. (As I
mentioned before, we already have the "noplainemail" config option,
but we should probably remove this in favor of using this new filter
API.)
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Policy on global variables

[Jason A. Donenfeld]

On Thu, Jan 16, 2014 at 10:34 PM, John Keeping  wrote:
>
> I'm not sure it makes much difference either way.  Even if we use
> libgit2, providing we're not processing more than one request at once we
> can still use a global cgit_context.

Well, the idea of moving to libgit2, in the first place, would be to
benefit from its reentrancy, so that we could process multiple
requests at once (potentially).
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Policy on global variables

[John Keeping]

On Thu, Jan 16, 2014 at 10:26:08PM +0100, Jason A. Donenfeld wrote:
> On Thu, Jan 16, 2014 at 10:21 PM, John Keeping  wrote:
> > The first step in this direction may actually be useful even if we stick
> > with embedding libgit.a.
> 
> So what do you think ought to be done with the global-ctx patch? Merge
> it, and then refactor afterward (whenever we "step in this
> direction"), to get rid of the global? Or use what we have now
> (without the patch) as a starting point for gradually getting rid of
> the global?

I'm not sure it makes much difference either way.  Even if we use
libgit2, providing we're not processing more than one request at once we
can still use a global cgit_context.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Policy on global variables

[Jason A. Donenfeld]

On Thu, Jan 16, 2014 at 10:21 PM, John Keeping  wrote:
> The first step in this direction may actually be useful even if we stick
> with embedding libgit.a.

So what do you think ought to be done with the global-ctx patch? Merge
it, and then refactor afterward (whenever we "step in this
direction"), to get rid of the global? Or use what we have now
(without the patch) as a starting point for gradually getting rid of
the global?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Policy on global variables

[John Keeping]

On Thu, Jan 16, 2014 at 07:38:02PM +0100, Jason A. Donenfeld wrote:
> On Thu, Jan 16, 2014 at 2:08 PM, John Keeping  wrote:
> >
> > I had a look at porting to libgit2 about a year ago and it mostly isn't
> > too bad.  IIRC the only problematic area is the graph output which we
> > currently get from libgit.a but would have to do ourselves if we switch
> > to libgit2.
> 
> Are there any downsides of doing this? I know we've put a lot of work
> into cozying up with internal git utility functions and their build
> system. Would we have to reimplement a lot of this? Would it be worth
> it? Are there general benefits of using libgit2 over what we have now?
> Are there general downsides?

Given the CGit and Git are both GPLv2, we could always just take
strbuf.[ch] and the argv-array bits from git.git and copy them into
CGit.  Likewise the test suite could switch to using Sharness with very
little effort.

So I don't think the recent changes towards using more bits of Git
actually have too much impact here.

> More importantly, is this something you would be willing to do, if we
> decided it was the best direction?

I won't have time to do this in the near future.

The first step in this direction may actually be useful even if we stick
with embedding libgit.a.  Re-writing the commit graph drawing ourselves
could allow prettier output than the ASCII we inherit from Git.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Policy on global variables

[Jason A. Donenfeld]

On Thu, Jan 16, 2014 at 2:08 PM, John Keeping  wrote:
>
> I had a look at porting to libgit2 about a year ago and it mostly isn't
> too bad.  IIRC the only problematic area is the graph output which we
> currently get from libgit.a but would have to do ourselves if we switch
> to libgit2.

Are there any downsides of doing this? I know we've put a lot of work
into cozying up with internal git utility functions and their build
system. Would we have to reimplement a lot of this? Would it be worth
it? Are there general benefits of using libgit2 over what we have now?
Are there general downsides?

More importantly, is this something you would be willing to do, if we
decided it was the best direction?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

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

[Kyle J. McKay]

On Jan 16, 2014, at 03:18, Jason A. Donenfeld wrote:
On Thu, Jan 16, 2014 at 4:28 AM, Kyle J. McKay   
wrote:
Looking at the new docs for this [4] I don't see an option to  
filter owners.
I see that the owner is passed in as "CGIT_REPO_OWNER", but I don't  
see an
opportunity to produce the owner markup.  Is it there and I'm just  
not

seeing it?


This is certainly interesting, though slightly different, as the
owners aren't attached to email authors, like in the commits. Still
though, something worth exploring. There are a number of options for
this. I could add a filter wrapper around the owner column values. Or,
I could implement the search capability directly in cgit. Or other
things.


Here's the relevant change to gitweb on repo that supports this:

  # owner link hook given owner name (full and NOT obfuscated)
  # should return full URL-escaped link to attach to owner, for  
example:

  #sub { return "/showowner.cgi?owner=".CGI::Util::escape($_[0]); }
  our $owner_link_hook = undef;

And we use this hook:

  $owner_link_hook =
sub { url_path($Girocco::Config::webadmurl).
  "/projlist.cgi?name=".md5_hex($_[0]); };


First, though -- is repo.or.cz considering moving to cgit from its
modified gitweb? Is this a serious investigation into cgit as a
replacement?


Replacement's a strong word at this point.  I've been looking into it  
ever since I found this in the Apache config:


  RewriteRule ^/c/(.*)$ /cgit.cgi?url=$1 [L,QSA]

So a cgit version of the cgit mirror would be http://repo.or.cz/c/cgit.git 
 (don't bother, 404 at this point).


I do slip in the occasional preparatory work [1] to make cgit support  
easier when I become aware of such things. :)


Looking at top, gitweb is clearly a CPU pig on repo.or.cz (git clones  
can also be piggy but I expect that to drop significantly when the new  
pack bitmap support is deployed).  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.  :)


The repo.or.cz pages also try to make the email addresses more  
difficult to
scrape by generating peculiar markup (the HTML::Email::Obfuscate  
package) so

conceivably this could be handled in the owner filter as well.


We have the noplainemail config flag already. Perhaps this could be
phased out, preferring the email-filter and commit-filter instead.


As you can see from the hook text above the repo gitweb hook only  
offers the ability to attach a link, it doesn't actually let one  
generate the markup or change the displayed owner name.  That's all I  
really need.  On the project list page [3] there are thousands of  
these, so running a shell script for each one is a non-starter.  A  
simple regex is not good enough either because it needs to generate  
the md5 hash (probably ought to be md5_hex(lc($_[0])) too -- another  
TODO item).


Kyle

[1] 
http://repo.or.cz/w/girocco.git/commit/abe9554c1bf1699ac0aaea08639310f404458d14
[2] http://repo.or.cz/w/girocco.git/blob/HEAD:/README
[3] http://repo.or.cz/w?a=project_list

___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Policy on global variables

[John Keeping]

On Thu, Jan 16, 2014 at 12:31:15PM +0100, Jason A. Donenfeld wrote:
> On Thu, Jan 16, 2014 at 11:47 AM, Eric Wong  wrote:
> > Lars Hjemli  wrote:
> >> Supporting something like FCGI in cgit will require a fork(2) for each
> >> request, before invoking libgit.a functions, since these functions are
> >> not generally reentrant (they tend to use global state and/or
> >> inconveniently die(3)).
> >
> > Unfortunately true for now, but libgit.a could evolve (or cgit can use
> > something like libgit2 instead).
> 
> Cgit is unlikely to move to libgit2 in the near future. (Unless
> someone is willing to do the job and argue for why it's preferred over
> mainline git, beyond its reentrancy...)
> 
> I guess, though, libgit.a is likely to never evolve to receive
> reentrant functions and do away with die() (though the die calls could
> easily be circumvented by hooking libc's exit...yuck), because libgit2
> exists for this reason.

I had a look at porting to libgit2 about a year ago and it mostly isn't
too bad.  IIRC the only problematic area is the graph output which we
currently get from libgit.a but would have to do ourselves if we switch
to libgit2.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Time Invariant String Comparison

[Jason A. Donenfeld]

Hi guys,

Over at cgit [1] we use Lua for our authentication framework [2]. One
thing we're doing wrong is lines like these:

if password == post["password"] then

Since an attacker can control the post params, this test is vulnerable
to a timing attack, by which an attacker could determine the password
one character at a time by analysis of response time.

What I'm looking for is some clever way in Lua to compare two strings
in a time invariant way. Any suggestions?

Thanks,
Jason


[1] http://git.zx2c4.com/cgit/
[2] http://git.zx2c4.com/cgit/tree/filters/simple-authentication.lua
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

TODO list for next release

[Jason A. Donenfeld]

Hi guys,

We're getting close to release time. Here's what I'm hoping for
between now and then:

- Review lua
- Review authentication filter
- Write tests for authentication filter
- Implement time invariant string compare function in lua for
simple-authentication.lua
- Potentially merge or reject lf/global-ctx
- Lots of eyeballs on all the recent churn in the master branch


Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Policy on global variables

[Jason A. Donenfeld]

On Thu, Jan 16, 2014 at 11:47 AM, Eric Wong  wrote:
> Lars Hjemli  wrote:
>> Supporting something like FCGI in cgit will require a fork(2) for each
>> request, before invoking libgit.a functions, since these functions are
>> not generally reentrant (they tend to use global state and/or
>> inconveniently die(3)).
>
> Unfortunately true for now, but libgit.a could evolve (or cgit can use
> something like libgit2 instead).

Cgit is unlikely to move to libgit2 in the near future. (Unless
someone is willing to do the job and argue for why it's preferred over
mainline git, beyond its reentrancy...)

I guess, though, libgit.a is likely to never evolve to receive
reentrant functions and do away with die() (though the die calls could
easily be circumvented by hooking libc's exit...yuck), because libgit2
exists for this reason.

I am therefore tempted to follow Lars' suggestion, and merge lf/global-ctx.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

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

[Jason A. Donenfeld]

On Thu, Jan 16, 2014 at 4:28 AM, Kyle J. McKay  wrote:
> On repo.or.cz I've hooked up project owner to a link that shows a list of
> all projects owned by the same person.
>
> So, for example, the owner name is passed in and you end up getting back
> links like [1] and [2].  (You can see where this shows up by pulling up one
> of the project summary pages on repo.or.cz such as the cgit mirror [3].)
>
> Looking at the new docs for this [4] I don't see an option to filter owners.
> I see that the owner is passed in as "CGIT_REPO_OWNER", but I don't see an
> opportunity to produce the owner markup.  Is it there and I'm just not
> seeing it?

This is certainly interesting, though slightly different, as the
owners aren't attached to email authors, like in the commits. Still
though, something worth exploring. There are a number of options for
this. I could add a filter wrapper around the owner column values. Or,
I could implement the search capability directly in cgit. Or other
things.

First, though -- is repo.or.cz considering moving to cgit from its
modified gitweb? Is this a serious investigation into cgit as a
replacement?

>
> The repo.or.cz pages also try to make the email addresses more difficult to
> scrape by generating peculiar markup (the HTML::Email::Obfuscate package) so
> conceivably this could be handled in the owner filter as well.

We have the noplainemail config flag already. Perhaps this could be
phased out, preferring the email-filter and commit-filter instead.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: authentication support: work has begun!

[Jason A. Donenfeld]

On Wed, Jan 15, 2014 at 10:28 AM, Peter Wu  wrote:
> While the referrer part may not be that easily spoofable

Note that as of b826537 we no longer rely on the referer and instead
use a hidden html form with a secured value. This also doubles as CSRF
protection.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Policy on global variables

[Eric Wong]

Lars Hjemli  wrote:
> On Thu, Jan 16, 2014 at 2:00 AM, Jason A. Donenfeld  wrote:
> > On Thu, Jan 16, 2014 at 1:59 AM, Eric Wong  wrote:
> >> This.  I prefer we keep passing around the ctx variable to keep the code
> >> more flexible for future reuse.  Of course, IIRC git itself has this
> >> limitation, too...
> >
> > Can anyone confirm or deny this? Is it a pointless endeavor because of
> > git's design?
> 
> Supporting something like FCGI in cgit will require a fork(2) for each
> request, before invoking libgit.a functions, since these functions are
> not generally reentrant (they tend to use global state and/or
> inconveniently die(3)).

Unfortunately true for now, but libgit.a could evolve (or cgit can use
something like libgit2 instead).
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Policy on global variables

[Lars Hjemli]

On Thu, Jan 16, 2014 at 2:00 AM, Jason A. Donenfeld  wrote:
> On Thu, Jan 16, 2014 at 1:59 AM, Eric Wong  wrote:
>> This.  I prefer we keep passing around the ctx variable to keep the code
>> more flexible for future reuse.  Of course, IIRC git itself has this
>> limitation, too...
>
> Can anyone confirm or deny this? Is it a pointless endeavor because of
> git's design?

Supporting something like FCGI in cgit will require a fork(2) for each
request, before invoking libgit.a functions, since these functions are
not generally reentrant (they tend to use global state and/or
inconveniently die(3)).

Therefore, passing a pointer to a context variable serves no real
purpose since each request would be processed in a different child
process (thus having a private copy of the global context).

But FCGI support could still be a nice addition to cgit, since parsing
of cgitrc and/or scanning for repos could then be done once, in the
parent process.

-- 
larsh
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit