From: John Keeping j...@keeping.me.uk
This stops the code in cgit.c::print_repo needing to inspect the
cgit_filter structure, meaning that we can abstract out different filter
types that will have different fields that need to be printed.
Signed-off-by: John Keeping j...@keeping.me.uk
---
, evidently.
Jason A. Donenfeld (9):
filter: allow for cleanup hook for filter types
filter: basic write hooking infrastructure
filter: add preliminary lua support
filter: document lua filter type
filter: lua error reporting
filter: return on null filter from open and close
filter: add
Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com
---
filters/email-gravatar.py | 30 ++
1 file changed, 30 insertions(+)
create mode 100755 filters/email-gravatar.py
diff --git a/filters/email-gravatar.py b/filters/email-gravatar.py
new file mode 100755
index
functions are used (ui-patch or within git itself),
which has its own internal buffering, which makes it difficult to
interlace our function calls. So, we dlsym libc's write and then
override it in the link stage.
Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com
---
cgit.c | 2 ++
cgit.h | 1
and close_filter calls, and only reap the child
process at the end of the cgit process. For this reason, we add here a
cleanup function that is called at the end of cgit's main().
Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com
---
cgit.c | 1 +
cgit.h | 2 ++
filter.c | 85
Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com
---
filters/email-gravatar.lua | 25 +
filters/email-gravatar.py | 3 +++
2 files changed, 28 insertions(+)
create mode 100644 filters/email-gravatar.lua
diff --git a/filters/email-gravatar.lua b/filters/email
That would be much appreciated. Thanks Sebastian. Also, if there's
anything else that you worked on that didn't get picked up, now would
be a decent time to submit it for rereview.
___
CGit mailing list
CGit@lists.zx2c4.com
On Fri, Jan 10, 2014 at 10:06 AM, John Keeping j...@keeping.me.uk wrote:
This seems drastically over complicated.
So here's the situation. There's a lot of state that we're taking
advantage of in using processes that terminate, that needs to be
replicated:
*a* Sending arguments to the
Looks good, merged.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Seems reasonable. Merged.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
On Fri, Jan 10, 2014 at 3:38 PM, Lukas Fleischer c...@cryptocrack.de wrote:
We did only display enabled snapshot formats but we did not prevent from
downloading disabled formats when requested. Fix this by adding an
appropriate check.
Previously:
Looking through the archives, I stumbled across this neglected patch:
http://lists.zx2c4.com/pipermail/cgit/2012-June/000642.html
Anybody want to investigate and brush this up for merging currently?
___
CGit mailing list
CGit@lists.zx2c4.com
On Fri, Jan 10, 2014 at 6:20 PM, John Keeping j...@keeping.me.uk wrote:
I was also wondering if supporting unix:/path/to/socket would be
useful, then the filter would connect on a Unix socket, run and
disconnect, on the assumption that the administrator has a daemon
running to do the
this idea quite a bit. But the cost of forking indeed seems
a bit high -- some listings have many many authors all at once. I'll
investigate a little bit.
--
Jason A. Donenfeld
Deep Space Explorer
fr: +33 6 51 90 82 66
us: +1 513 476 1200
www.jasondonenfeld.com
Hey folks,
I'm thinking about this filtering situation w.r.t. gravatar and
potentially running multiple filters on one page. Something I've been
considering is implementing a simple dlopen() mechanism for filters,
if the filter filename starts with soname: or lib: or similar, so
as to avoid the
On Fri, Jan 10, 2014 at 3:11 AM, Jason A. Donenfeld ja...@zx2c4.com wrote:
Problems abound. This has race condition issues, where the parent
process will SIGSTOP the child before the child can write its output.
This could be fixed with a more complicated signaling protocol, but
that's more
Hey folks,
To speed things up with the merges and reviews of patches on this
list, I've given Lukas Fleischer commit access. He's going to be
helping me maintain the project. We'll each be merging and committing
patches to jd/staging and lf/staging, and from there onto master. I'll
be updating
Much better. Updating the link to that.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Hi Folks,
Merging of patches will resume on December 6th at 15h00 CEST. I will also
be bringing Lukas Fleischer on board to help out with the review and
merges, so that we can maintain a good pace of commits.
Talk to you all next week.
Jason
___
CGit
On Tue, Aug 27, 2013 at 3:27 AM, Lukas Fleischer c...@cryptocrack.dewrote:
+ } else {
+ /*
+* SHA-1 of an empty tree. We might be better off
not
+* hardcoding this.
+*/
+
On Thu, Aug 22, 2013 at 2:48 PM, Lukas Fleischer c...@cryptocrack.de wrote:
+ rev.max_parents = 1;
Good catch. This is what builtin/log.c does in get_patch_ids as well.
Might be a good function to look at for comparison, in case you aren't
already doing that.
This will be reviewed as soon as I'm back home from vacation (which will be
soon!), but for now, it's staging in:
http://git.zx2c4.com/cgit/log/?h=lf/diffs
If you also implement the git-format-patch improvements as discussed in the
RFE, go ahead and base it on this branch.
The relevant code is here:
if (ctx.cfg.section_from_path) {
n = ctx.cfg.section_from_path;
if (n 0) {
slash = rel.buf;
while (slash n (slash = strchr(slash, '/')))
n--;
Caught up to mailing list posts. Thanks for the fix Lukas. Disregard prior
message.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Here is the function in question:
static int read_config_line(FILE *f, char *line, const char **value,
int bufsize)
{
int i = 0, isname = 0;
*value = NULL;
while (i bufsize - 1) {
int c = next_char(f);
if (!isname (c == '#' || c == ';'))
Looks mostly okay. While you're at it, what about fixing the BUG mentioned
at the bottom of cgitrc.5.txt?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
On Wed, May 29, 2013 at 10:20 AM, Christian Hesse l...@eworm.de wrote:
I was wondering why cgit does not ship a favicon by default. Could not find
any discussions about that, so I hope I do not raise a discussion that has
already been decided.
Looks great! Thanks Christian. Merged into master.
Hi Kurt,
This issue has now been fixed with CGit v0.9.2:
The announcement may be read here:
http://lists.zx2c4.com/pipermail/cgit/2013-May/001394.html
Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
On Mon, May 27, 2013 at 2:30 PM, Jan Lieskovsky jlies...@redhat.com wrote:
Can you provide a patch that would apply against v0.9.1 version too? Or
would this be just problem of master branch code?
I could, but you'd be much better off just upgrading to v0.9.2.
To those of you for whom C is easier than any human language, here's
specifically what I have in mind:
http://git.zx2c4.com/cgit/commit/?h=jd/auto-aboutid=82c6ed9a7bbc77f207f5e428a60bcbff005e587b
Code-wise it's simple, but it could potentially be slightly disruptive.
Hi Kurt,
As mentioned in early messages to oss-sec, I've inherited
maintainership of the cgit codebase and am gradually auditing it.
Today I found a nasty directory traversal:
http://somehost/?url=/somerepo/about/../../../../etc/passwd
This should be pretty straightforward to categorize.
401 - 431 of 431 matches
Mail list logo