Re: [PATCH] native inline gravatar

2018-07-03 Thread Andy Green
On 07/04/2018 08:14 AM, Jason A. Donenfeld wrote: On Wed, Jul 4, 2018 at 2:01 AM Andy Green wrote: doesn't use any filters for syntax highlight and markdown render, it's all done in clientside JS. The gravatar is done using this patch. If you're into doing things clientside, you could do

Release plan for 1.2

2018-07-03 Thread Jason A. Donenfeld
Hey guys, Seeing as there hasn't been a release for a while, it seems prudent that we get one out fairly soon. Indeed there have been a lot of new things added and code refactored since 1.1. There's still the possibility of getting the render view improvements ready for 1.2 -- if those are

Re: Release plan for 1.2

2018-07-03 Thread Christian Hesse
"Jason A. Donenfeld" on Wed, 2018/07/04 03:23: > Hey guys, > > Seeing as there hasn't been a release for a while, it seems prudent > that we get one out fairly soon. Indeed there have been a lot of new > things added and code refactored since 1.1. There's still the > possibility of getting the

Re: [PATCH] native inline gravatar

2018-07-03 Thread Jason A. Donenfeld
On Wed, Jul 4, 2018 at 2:44 AM Andy Green wrote: > > looked at in depth. (See the list archives.) Our last conclusion from > > examining it was that so much of libgit is not re-entrant, and so we'd > > need to move to something like libgit2 for this to be feasible. Too > > many globals, etc. > >

Re: [PATCH] native inline gravatar

2018-07-03 Thread Andy Green
On 07/04/2018 08:34 AM, Jason A. Donenfeld wrote: On Wed, Jul 4, 2018 at 2:28 AM Andy Green wrote: I looked at it, but there's no md5 api in JS... you have to do it by hand in JS. It's possible but I think it might be slow if it hits a page of 50 different email addresses. MD5 is really

Re: [PATCH] native inline gravatar

2018-07-03 Thread Jason A. Donenfeld
Sorry, but not a chance something like this can be accepted. This is exactly the reason we put the time into making the Lua scripting support. Is your reason for implementing this C performance? In that case, could you send some performance metrics and some details about your performance

Re: [PATCH v2 02/15] gcc8.1: fix strncat warning

2018-07-03 Thread Andy Green
On 07/04/2018 07:45 AM, Jason A. Donenfeld wrote: Hi Andy, I can't actually reproduce this with gcc 8.1.0. Could you send me the output of your `gcc -v`? $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper

Re: [PATCH v2 02/15] gcc8.1: fix strncat warning

2018-07-03 Thread Jason A. Donenfeld
On Wed, Jul 4, 2018 at 1:48 AM Andy Green wrote: > $ rpm -q gcc > gcc-8.1.1-1.fc28.x86_64 > > It's the current package on Fedora 28. 8.1.1, thanks. ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] native inline gravatar

2018-07-03 Thread Jason A. Donenfeld
On Wed, Jul 4, 2018 at 2:01 AM Andy Green wrote: > doesn't use any filters for syntax highlight and markdown render, it's > all done in clientside JS. The gravatar is done using this patch. If you're into doing things clientside, you could do gravatar clientside too of course... > This of

Re: [PATCH v4 00/16] Render READMEs inline in tree view

2018-07-03 Thread Jason A. Donenfeld
On Tue, Jul 3, 2018 at 9:53 PM John Keeping wrote: > If I can have one more bikeshed... I wonder if "about-content" is better > than "about-readme", the latter feels a bit like we're saying this same > thing twice. Bikeshed granted. :) Yes, that sounds sensible.

Re: [PATCH v2 02/15] gcc8.1: fix strncat warning

2018-07-03 Thread Jason A. Donenfeld
Hi Andy, I can't actually reproduce this with gcc 8.1.0. Could you send me the output of your `gcc -v`? Thanks, Jason ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] native inline gravatar

2018-07-03 Thread Andy Green
On 07/04/2018 07:49 AM, Jason A. Donenfeld wrote: Sorry, but not a chance something like this can be accepted. This is exactly the reason we put the time into making the Lua scripting No worries. support. Is your reason for implementing this C performance? In that case, could you send

Build failed in Jenkins: cgit-master #180 - origin/master - a35da29

2018-07-03 Thread Pelagic Jenkins (Public)
See Changes: [Jason] snapshot: support tar signature for compressed tar -- Started by an SCM change Building in workspace

Build failed in Jenkins: cgit-master-get-git #179 - origin/master - a35da29

2018-07-03 Thread Pelagic Jenkins (Public)
See Changes: [Jason] snapshot: support tar signature for compressed tar -- Started by an SCM change Building in workspace

Build failed in Jenkins: cgit-master #181 - origin/master - 899f415

2018-07-03 Thread Pelagic Jenkins (Public)
See Changes: [Jason] extra-head-content: introduce another option for meta tags -- Started by an SCM change Building in workspace

Jenkins build is back to normal : cgit-master-get-git #180 - origin/master - 7ba4196

2018-07-03 Thread Pelagic Jenkins (Public)
See ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit

Jenkins build is back to normal : cgit-master #182 - origin/master - 7ba4196

2018-07-03 Thread Pelagic Jenkins (Public)
See ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH v3 1/1] snapshot: support tar signature for compressed tar

2018-07-03 Thread Jason A. Donenfeld
I've merged a variant of the patch, and it appears to be working well. Thanks guys! ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] css: darken the footer

2018-07-03 Thread Jason A. Donenfeld
On Mon, Jul 2, 2018 at 9:11 AM Christian Hesse wrote: > > Christian Hesse on Fri, 2018/06/08 07:21: > > From: Christian Hesse > > > > The footer was nearly invisible, hard to read at best. Let's make it > > a bit darker. > > This stayed in ch/for-jason. Any feedback? Fairly subjective, but I

Re: [PATCH v4 00/16] Render READMEs inline in tree view

2018-07-03 Thread Jason A. Donenfeld
Hey John, On Thu, Jun 28, 2018 at 10:29 AM John Keeping wrote: > Yeah, I don't think there's any way to avoid exec'ing twice in source > view - we need to run the source filter for output and we need the > render filter to tell us whether we should output a link to the rendered > content. Let's

Re: [PATCH v4 00/16] Render READMEs inline in tree view

2018-07-03 Thread John Keeping
On Tue, Jul 03, 2018 at 09:34:26PM +0200, Jason A. Donenfeld wrote: > On Thu, Jun 28, 2018 at 10:29 AM John Keeping wrote: > > Yeah, I don't think there's any way to avoid exec'ing twice in source > > view - we need to run the source filter for output and we need the > > render filter to tell us