Janus -- I added you to the list manually, if you want to try resending
this yourself.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Good thinkin, Lincoln.
Merged.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Seems like a reasonable enough way of handling it. Thanks John. I've merged
this.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Excellent, thank you.
Merged.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Hey Tobias,
Sorry for the delay on this. Would you mind rebasing it on master, and
resubmitting? I'll merge it ASAP.
Thanks,
Jason
On Sat, Apr 19, 2014 at 6:05 PM, Tobias Dreher
wrote:
> Hello everyone,
>
> Currently cgit only outputs the line "Repository seems to be empty" if a
> repository i
Oh, major bummer. I'll revert.
What's upstream's stance on that?
On Dec 24, 2014 12:13 PM, "Lukas Fleischer" wrote:
> On Wed, 24 Dec 2014 at 09:40:07, Jason A. Donenfeld wrote:
> > On Wed, Dec 24, 2014 at 1:01 AM, Lukas Fleischer
> > wrote:
> >
On Wed, Dec 24, 2014 at 1:01 AM, Lukas Fleischer
wrote:
>
> I don't think this is a good idea (I raised concerns weeks ago but
> forgot to Cc the mailing list).
>
Shucks on the CC.
I'd like to hear more opinions.
*Who out there is deploying cgit on boxes that don't have tar's -J?*
_
Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Very nice, thanks. Merged!
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Ahh yes, of course -- John has done it, and it's been merged
here: ddfaef6bb28e697491b25bff5a7b260d44ce6ccf
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
I'd be happy to merge a commit that adds this functionality, if anybody
wants to take a stab at it. Otherwise, I'll give it a go in the next few
weeks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Merged a variant of this.
xz is less commonly deployed, but I think modernization is a good thing in
this regard, so rolling with it.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Seems reasonable enough. Merged.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Sorry I didn't see this a few minutes ago. Rebased it myself against
master, and merged. Thanks for your work on this. Looking forward to
log-filter next!
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Merged this entire series. Cool to implement rel-vcs. Thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
On Fri, Aug 1, 2014 at 12:06 PM, Chris Burroughs
wrote:
>
> I think a "log-filter" with the same API sounds good and fits my use
> case. I'll take a stab at that after the owner-filter work.
>
Ready now, when you are.
___
CGit mailing list
CGit@lists.z
Hi Chris,
I like this patch, and I intend to merge it. Would you take care of John's
nitpicks, and rebase this against the current master, and I'll merge?
Sorry for the delay.
Thanks,
Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.
On Wed, Dec 17, 2014 at 5:19 AM, Lukas Fleischer
wrote:
> Use Git's built-in ident line splitting algorithm instead of
> reimplementing it. This does not only simplify the code but also makes
> sure that cgit is consistent with Git when it comes to author parsing.
>
Thank heavens!
> +
This is a good solution. Thanks for taking care of this Lukas. Merged.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Merging this, because it appears correct and necessary, but... *ugh*.
Does upstream have an official stance on why they don't make "src=//" easy?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Merged.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Merged.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Likewise, merged. Thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Hi folks,
I've been unavailable a bit, watching the commits and ideas pile up. Just
to give everyone an update, I'll be back beside a keyboard ready to commit
around Dec 15. Talk to you all then.
Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://l
Curious to know the motivation behind this patchset. Why would you want
stat-only?
Will review very soon.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Merged.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Merged. Thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
I would be okay with both scan-path deferment or simply augmenting the
documentation. I don't like the commit of this thread though.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Applied this series. Thanks John.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi folks,
CGit 0.10.2 is now available, as a mostly bug fix and cleanup release.
== CGit on the Web ==
* homepage: http://git.zx2c4.com/cgit/about/
* git repository: http://git.zx2c4.com/cgit/
* git clone: git://git.zx2c4.com/cgit
* mailing list: cg
Excellent, thank you.
Now one last thing:
Submit them to this list using git-send-email, so that the folks on the
list can review them inline. Otherwise, everyone will refuse to poke at
them. :\
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx
It still seems a bit hackish to me. I need to think about it more, or
hear some other ideas on it.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Cool, thanks.
> 2.0.1
Bleeding edge!
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
You've added a bunch of fprintf(stderr, "debugging blah...") in this commit
that I missed the first time through. Could you post a patch which removes
these?
--
Sent from my telephone.
On May 29, 2014 5:53 PM, "Christian Hesse" wrote:
> prefixcmp() and suffixcmp() have been remove, functionality
Hey folks,
There have been some critical bugs recently fixed, mostly discovered
by Konstantin Ryabitsev and fixed by John Keeping. I'm going to do a
0.10.2 release soon for these. If there are any other bugs or quick
fixes you want to get in before then, now would be a good time to post
them to th
That was fast! Merged.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
This looks good, but the new option needs documentation in cgitrc.5.txt.
Would you make this change, and then submit a cleaned up patchset to the
list?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Thanks for patching this John. Merged here:
http://git.zx2c4.com/cgit/commit/?id=2efb59ed0fa8eced79fa702bc47454d3406c3431
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Thanks John. I've merged this patch here:
http://git.zx2c4.com/cgit/commit/?id=4046e8ef66225928a4f0d2cd71479e401faf7c3b
I'll probably do a release soon that includes this.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo
Make sure you compile cgit with lua support. Check out the readme.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Merged, thanks!
If you want to send an addition patch layering on other 2.0 changes
(strip_prefix and such), feel free -- I'll be merging things.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Thanks. I'll have a look at this after the 26th.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Cool. Merges will happen last week in June. Thanks for sending this. Noted
in my list.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
On Mon, Jun 2, 2014 at 11:18 PM, Konstantin Ryabitsev wrote:
> Before I go look in the code, can someone tell me if the authentication
> support in cgit hides the repositories to which the user has no access,
> or just prevents accessing the actual content?
Just the actual content, but not the li
Hmm still not perfect though. Let's say I want a relative URL that is
out of the cgit root but still on the same domain...
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Clever solution.
But this breaks if we're ever including an image by an absolute URL.
Maybe we should simply document that git-relative images should be
linked via "../plain/" and leave it to the markdown author?
Or come up with some other clever hack?
___
Thanks for taking the time to do this. I'm sure it was tedious.
You introduced two additional whitespace errors in this patch, putting
spaces where a tab used to be. I cleared these up and committed it:
http://git.zx2c4.com/cgit/commit/?id=b431282c91deea24916578395d88084261410968
_
Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Dot six it is!
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Thanks for catching that. Your Jenkins is awesome.
http://git.zx2c4.com/cgit/commit/?id=88b93113235452d47e7ce474689327c43e64b843
Using the kernel.org mirror instead now.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/
On Thu, Mar 20, 2014 at 8:21 AM, Christian Hesse wrote:
> I would increase the opacity value a bit, but I do like it otherwise. :D
It's point four now. Make a suggestion and I'll change it to that. I
was having trouble deciding myself.
___
CGit mailing
Merged, thanks!
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
The footer has always been overrideable using the footer= in cgitrc, so
this won't anger anybody who cares about their footer.
---
Is this horrible? Or is this acceptable?
cgit.css| 7 +++
ui-shared.c | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/cgit.css b/cgit.cs
Very slick! Thanks for sending this onward.
Promptly stolen for . : )
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Cool! Merged to master.
What's the story with Libravatar? The FLOSS version? Do they bootstrap
from Gravatar or is it a totally different database?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
like to see for that:
* HTML5 compliance
* Line number anchors highlighting the current line in pure css / html
anchors
* git-blame support
* git-grep support
* More malloc()/free() cleanups
- --
Jason A. Donenfeld
www.zx2c4.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBA
Hey Stefan,
Can you keep the list up to date with pygments upstream? Has that
python3 change made it through? Before 0.10.1 release (probably
tomorrow), should we switch the highlight script back to python3? Or
is pygments upstream still not released?
Thanks,
Jason
___
Lukas' analysis seems correct to me. Merging.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
On Thu, Feb 20, 2014 at 9:07 PM, Lukas Fleischer wrote:
> Suggestions for better wording welcome, by the way. I also think that
> the already existing text "Negative values have infinite ttl" sounds a
> bit strange. Opinions?
Fixed the docs up with an additional commit, and committed yours below
Lukas "Lightspeed" Fleischer.
Thanks for the commit. Merged!
On Thu, Feb 20, 2014 at 8:58 PM, Lukas Fleischer wrote:
> No code changes required, just bump the submodule and Makefile versions.
>
> Signed-off-by: Lukas Fleischer
> ---
> Makefile | 2 +-
> git | 2 +-
> 2 files changed, 2 in
s/this type of pages/this type of page/g
--
Sent from my telephone.
On Feb 20, 2014 8:59 PM, "Lukas Fleischer" wrote:
> If time-to-live is set to zero, we don't need to regenerate the cache
> slots on every request. Instead, just skip the caching process and
> immediately provide the dynamicall
On Thu, Feb 20, 2014 at 8:33 PM, Christian Hesse wrote:
>
> Do you want to go with git 1.9.0 or keep 1.8.5 for this maintenance release?
I'd love to pop it up to 1.9.0, as well. AFAIK, nothing drastic
happens, but I haven't looked into it. If you'd like to provide a
patch for that, t'would be muc
Looks like kernel.org makes some changes. Do we want to adopt any of
these? Some of them are pretty, like the even/odd background. Others
I'm not sure what they do...
--- cgit.css2014-02-20 20:07:39.0 +0100
+++ cgit-korg.css 2013-02-28 20:16:48.0 +0100
@@ -59,6 +59,7 @@
Hey guys,
Last release was huge. A handful of little commits fixing small bugs
has been piling up since our last big feature release. So I think
sometime toward the end of next week, I'm going to release a 0.10.1
for bug fixes. Nothing huge. Nothing with big press releases and
noise. Just somethin
Okay after applying the patch I no longer receive this bug, so
presumably this was the correct fix. Committed to master.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
I haven't had any time to work through all the logic for why this
might be the case. Are any volunteers who can triple check that the
change in logic here is not an issue? I'd like to be extra certain
before merging this.
On Tue, Feb 4, 2014 at 9:07 PM, Lukas Fleischer wrote:
>
> On Tue, 04 Feb 2
On Sat, Feb 8, 2014 at 2:45 PM, Lukas Fleischer wrote:
>
> Yes, -1 is documented in the man page and it is quite clear that 0 means
> "always expire" (directly follows from the general description of what
> the *-ttl variables do).
I'd like to explicitly have this documented before merging it. W
Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
s, but I suspect it might have to
do with this uninitialized data.
Signed-off-by: Jason A. Donenfeld
---
shared.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/shared.c b/shared.c
index 7e88bbd..8ed14c0 100644
--- a/shared.c
+++ b/shared.c
@@ -368,6 +368,7 @@ void cgit_diff_tree(con
On Feb 10, 2014 2:45 PM, "Martin Meduna" wrote:
>
> Hi,
> is there any authentication into cgit?
Yes. Please see the documentation for auth-filter in cgitrc.5.txt, as well
as the included example lua script, in filters/.
___
CGit mailing list
CGit@lists
> On Feb 6, 2014 10:07 PM, "Lukas Fleischer" wrote:
>
> This is different. -1 means "never expire". 0 means "always expire".
Ahh perfect -- this is exactly the type of distinction I was looking for.
Do we have this documented?
___
CGit mailing list
CGit
er of caching and never
> deliver outdated pages at the same time.
>
> What do you think about that?
>
> Regards,
> Lukas
> ___
> CGit mailing list
> CGit@lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo
On Wed, Feb 5, 2014 at 10:46 AM, Lukas Fleischer wrote:
>
> /* If the cache is disabled, just generate the content */
> - if (size <= 0) {
> + if (size <= 0 || ttl == 0) {
> fn();
> return 0;
> }
Apparently we already special case ttl fo
On Wed, Feb 5, 2014 at 10:46 AM, Lukas Fleischer wrote:
> This can be used to specify the TTL for snapshots. Snapshots are usually
> static and do not ever change. On the other hand, tarball generation is
> CPU intensive.
>
> One use case of this setting (apart from increasing the lifetime of
> sn
On Sat, Feb 1, 2014 at 4:10 PM, Fabien C. wrote:
>
> Here is yet another version (+ patch file):
>
> if test "$(git rev-parse --git-dir 2>/dev/null)" = '.git'
> then
> V=$(git describe --abbrev=4 HEAD 2>/dev/null)
> fi
Merged, thanks.
___
CGit
zx2c4@thinkpad ~ $ cat a.c
static int cmp_age(int age1, int age2)
{
if (age1 != 0 && age2 != 0)
return age2 - age1;
if (age1 == 0 && age2 == 0)
return 0;
if (age1 == 0)
return +1;
return -1;
}
static int cmp_age2(int age1,
On Tue, Feb 4, 2014 at 8:22 PM, Lukas Fleischer wrote:
>
> return age2 - age1;
> -static int cmp_age(int age1, int age2)
> -{
> - if (age1 != 0 && age2 != 0)
> - return age2 - age1;
> -
> - if (age1 == 0 && age2 == 0)
> - return 0;
> -
> - if (age1
> From a6844137677cfe782c7ef60c8547e18a81fca6e2 Mon Sep 17 00:00:00 2001
> From: Fabien C.
> Date: Fri, 31 Jan 2014 23:19:43 +0100
> Subject: [PATCH] gen-version.sh: check if git is available before trying to
> call it
> Some people may clone the cgit repository and compile within a sandbox
> or
Excellent! This is much better than what we had before. Merged:
http://git.zx2c4.com/cgit/commit/?id=44ccae4227060f91c60ad45de1188e728ce8af0d
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
It looks like we get description from gitweb.description, inside the git config:
else if (!strcmp(key, "gitweb.description"))
config_fn(repo, "desc", value);
We alternatively get it from the description file:
if (repo->desc == cgit_default_repo_desc || !repo->desc
The test should no longer fail when Lua isn't compiled in. I've
commited these patches:
http://git.zx2c4.com/cgit/commit/?id=6a1563343c48f9e38b85f39f4a95c89ea0f46a60
http://git.zx2c4.com/cgit/commit/?id=f759cc0f08c195940de05d5394f7b1ad4d44365e
___
CGit m
zx2c4@thinkpad ~ $ cat /usr/lib/pkgconfig/lua.pc
# lua.pc -- pkg-config data for Lua
# vars from install Makefile
# grep '^V=' ../Makefile
V= 5.1
# grep '^R=' ../Makefile
R= 5.1.5
# grep '^INSTALL_.*=' ../Makefile | sed 's/INSTALL_TOP/prefix/'
prefix= /usr
INSTALL_BIN= ${prefix}/bin
INSTALL_INC=
On Mon, Jan 20, 2014 at 9:57 AM, Ferry Huberts wrote:
> Ok, I needed to install lua-devel (Fedora 20)
>
> This should probably be detected.
> For example by using pkg-config, like mentioned in the other thread I just
> read while catching up :-)
>
> IMHO It's a good idea to use pkg-config to get/t
On Sun, Jan 19, 2014 at 3:13 PM, Jason A. Donenfeld wrote:
> Would you mind sending another commit where you implement this for the
> read() write() situation in authenticate_post() on
> http://git.zx2c4.com/cgit/tree/cgit.c#n624 ? Still bounding it to
> MAX_AUTHENTICATION_POST_BY
On Sat, Jan 18, 2014 at 9:25 PM, Sebastian Andrzej Siewior
wrote:
> cgit_tree_link("tree", NULL, "button", NULL, NULL,
> NULL);
> + cgit_git_link();
> @@ -284,6 +284,41 @@ void cgit_tree_link(const char *name, const char *title,
> const char *class,
On Sat, Jan 18, 2014 at 9:24 PM, Sebastian Andrzej Siewior
wrote:
> If the downloads are disabled one gets only ugly "commit sha1". With
> downloads enabled you see the file name with different extensions a few
> times.
> This patches changes it a little. Instead of printing the hash number it
> p
Excellent, thanks Sebastian! I've merged this commit.
Would you mind sending another commit where you implement this for the
read() write() situation in authenticate_post() on
http://git.zx2c4.com/cgit/tree/cgit.c#n624 ? Still bounding it to
MAX_AUTHENTICATION_POST_BYTES, but not having to copy it
On Sat, Jan 18, 2014 at 10:32 PM, Jamie Couture wrote:
> Hmm. It looks like struct stat lock_st member, introduced in
> 939d32fd, was never used anywhere in cgit. Would it make sense to
> separate this line in a differnt commit, explaining the unused
> member should be removed?
I noticed this to
eventually have success or error out.
Signed-off-by: Jason A. Donenfeld
---
What do you guys think of doing this? Some people don't have
pkg-config... or something? Not sure if this is the best approach but...
cgit.mk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/cg
On Fri, Jan 17, 2014 at 8:32 PM, John Keeping wrote:
> Presumably you are OK with this having the same latency as the existing
> cache mechanism. The simplest implementation will probably be to keep
> the existing "cache valid?" check and re-scan repositories as we
> currently do.
Or even just s
On Fri, Jan 17, 2014 at 8:29 PM, Konstantin Ryabitsev wrote:
>
> The process that updates the repositories may not have permissions to
> send SIGUSR1 to the fcgid process -- either because they are running as
> different users or because there are SELinux policies preventing it.
>
> It's really be
On Fri, Jan 17, 2014 at 8:08 PM, Félix C. Morency
wrote:
> You should add pkg-config to the list of dependencies in the README. It is
> required if you want to build with Lua support. Also, it might be a good
> idea to check for pkg-config presence in the Makefile.
Thanks for the report; this is
On Fri, Jan 17, 2014 at 5:53 PM, John Keeping wrote:
> But scan for repos is caught by the cache most of the time, and
> presumably even if we run persistently we still need to do that
> periodically (or use inotify); or do we just rely on the process being
> replaced when the set of repositories
On Fri, Jan 17, 2014 at 5:38 PM, Jason A. Donenfeld wrote:
> On Fri, Jan 17, 2014 at 5:28 PM, John Keeping wrote:
>> I really can't see this being sensible without moving to libgit2. As
>> long as we stick with libgit.a then we need to fork for each request so
>>
On Fri, Jan 17, 2014 at 5:28 PM, John Keeping wrote:
> I really can't see this being sensible without moving to libgit2. As
> long as we stick with libgit.a then we need to fork for each request so
> I'm not sure there's much benefit to supporting FastCGI without moving
> to something that lets u
401 - 500 of 708 matches
Mail list logo
