On Fri, Jan 10, 2014 at 03:11:54AM +0100, Jason A. Donenfeld wrote:
> On Fri, Jan 10, 2014 at 2:41 AM, Jason A. Donenfeld wrote:
> > and does its thing per usual. At the end, however, it does not exit.
> > Instead of waitpid()ing on it in close filter, we SIGSTOP it, put the
> > fds back in place,
Since the introduction of selective snapshot format configuration in
dc3c9b5 (allow selective enabling of snapshots, 2007-07-21), we allowed
seven different delimiters for snapshot formats, while the documentation
has always been clear about spaces being the only valid delimiter:
The value is
This is a preparation for replacing all prefix checks with either
strip_prefix() or starts_with() when Git 1.8.6 is released.
Signed-off-by: Lukas Fleischer
---
cgit.c | 18 +-
parsing.c| 12 ++--
scan-tree.c | 2 +-
ui-refs.c| 4 ++--
ui-shared.c | 2 +
Use Git string lists instead of str{spn,cspn,ncmp}() magic. This
significantly improves readability.
Signed-off-by: Lukas Fleischer
---
shared.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/shared.c b/shared.c
index 1f6310a..01197f1 100644
--- a/s
Use suffixcmp() from Git instead of reimplementing it. This is a
preparation for moving to ends_with() in Git 1.8.6.
Signed-off-by: Lukas Fleischer
---
ui-snapshot.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/ui-snapshot.c b/ui-snapshot.c
index 901c0c9..8f82119 100
Am 08.01.2014 16:19, schrieb Jason A. Donenfeld:
> Okay reading this closer, it seems what the one in-tree could benefit from is:
>
> - Expanded list of filename mappings, made more generic than what you
> have in your script, but basically the same idea. -- { "pkgbuild":
> "bashlexer", "cmakelist
* Formatting and spelling fixes.
* A bit mask with the size of one byte only allows for storing 8 (not
255!) different flags.
Signed-off-by: Lukas Fleischer
---
cgit.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/cgit.c b/cgit.c
index f4262d8..d74b0f
When parsing command line arguments, no pair of command line options can
ever match simultaneously. Use "else if" blocks to reflect this. This
change improves both readability and speed.
Signed-off-by: Lukas Fleischer
---
Based on the patches I sent earlier today.
cgit.c | 29 ++
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.
Also, add a test case that checks whether downloading disabled snapshot
formats is denied, as expected.
Signed-off-by: Lukas Fleischer
--
On Fri, Jan 10, 2014 at 03:38:06PM +0100, Lukas Fleischer 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.
>
> Also, add a test case that checks whether downloading disabled s
On Fri, 10 Jan 2014 at 15:50:14, John Keeping wrote:
> On Fri, Jan 10, 2014 at 03:38:06PM +0100, Lukas Fleischer wrote:
> [...]
> > +test_expect_success 'try to download a disabled snapshot format' '
> > + cgit_url "foo/snapshot/master.tar.xz" |
> > + grep "Unsupported snapshot format"
>
>
On Fri, Jan 10, 2014 at 10:06 AM, John Keeping 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 program, and distingu
Looks good, merged.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
I don't really like removing this, even though it's undocumented. But
I looked where this patch series is headed, and I like that more, so
I'll apply this. Merged.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Great. Merged.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Thank goodness gracious. 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 2:55 PM, Lukas Fleischer wrote:
> * A bit mask with the size of one byte only allows for storing 8 (not
> 255!) different flags.
Haha. Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/li
On Fri, Jan 10, 2014 at 3:38 PM, Lukas Fleischer 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:
http://lists.zx2c4.com/pipermail/cgit/2012-June/000641.html
http
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
http://list
On Fri, Jan 10, 2014 at 2:07 PM, Stefan Tatschner wrote:
> I have created an upstream pull request and it got merged after 30
> seconds [1]. Moreover it seems like the cmakelists.txt thing was also
> fixed [2].
Nice! Great!
>
> Should I remove the filename mapping thing in my patch according to
On 10.01.2014 16:57, Jason A. Donenfeld wrote:
> On Fri, Jan 10, 2014 at 10:06 AM, John Keeping 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
> replic
On Fri, 10 Jan 2014 at 17:11:46, Jason A. Donenfeld wrote:
> On Fri, Jan 10, 2014 at 3:38 PM, Lukas Fleischer 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.
>
> Previ
On Fri, Jan 10, 2014 at 06:12:25PM +0100, Florian Pritz wrote:
> On 10.01.2014 16:57, Jason A. Donenfeld wrote:
> > On Fri, Jan 10, 2014 at 10:06 AM, John Keeping wrote:
> >>
> >> This seems drastically over complicated.
> >
> > So here's the situation. There's a lot of "state" that we're taking
On 10/01/14 12:20 PM, John Keeping 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 filtering.
As an administrator, I
On Fri, Jan 10, 2014 at 6:12 PM, Florian Pritz wrote:
>
> Isn't this (fast scripting with lots of features) when people normally
> start using lua?
>
This would have the same challenges as using .so files, w.r.t. hooking
write() (or the html functions), but would be very interesting indeed,
becau
On Fri, Jan 10, 2014 at 6:20 PM, John Keeping 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 filtering.
This has
On Fri, Jan 10, 2014 at 6:43 PM, Konstantin Ryabitsev wrote:
> As an administrator, I would be very reluctant from having to use this
> mechanism. Administrators generally hate daemons. :)
Ditto.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.z
On 10.01.2014 18:57, Jason A. Donenfeld wrote:
> On Fri, Jan 10, 2014 at 6:12 PM, Florian Pritz wrote:
>>
>> Isn't this (fast scripting with lots of features) when people normally
>> start using lua?
>>
>
> This would have the same challenges as using .so files, w.r.t. hooking
> write() (or the h
On Fri, Jan 10, 2014 at 09:03:24PM +0100, Florian Pritz wrote:
> On 10.01.2014 18:57, Jason A. Donenfeld wrote:
> > On Fri, Jan 10, 2014 at 6:12 PM, Florian Pritz wrote:
> >>
> >> Isn't this (fast scripting with lots of features) when people normally
> >> start using lua?
> >>
> >
> > This would
On 10.01.2014 21:11, John Keeping wrote:
> Forking and using Lua in the child is an interesting idea.
>
> I need to investigate how Lua generally deals with I/O, but it feels
> like it will be simpler to use a simple function interface than deal
> with slurping in the input in Lua.
Looks rather e
On Fri, Jan 10, 2014 at 09:25:18PM +0100, Florian Pritz wrote:
> On 10.01.2014 21:11, John Keeping wrote:
> > Forking and using Lua in the child is an interesting idea.
> >
> > I need to investigate how Lua generally deals with I/O, but it feels
> > like it will be simpler to use a simple function
On 10.01.2014 21:36, John Keeping wrote:
>> Looks rather easy to slurp stdin (from http://www.lua.org/pil/21.1.html):
>
> Interesting. But I think it will be simpler from both side if the
> interface is just a function call
source_filter could potentially get a rather long input and might not
ne
On Fri, Jan 10, 2014 at 9:03 PM, Florian Pritz wrote:
> How about using the current fork approach but instead of calling execvp
> use lua. I believe forks are pretty cheap on linux, it's the exec that's
> costly.
>
> If we do it like that we could reuse stdin/stdout, we could pass
> arguments via
On Fri, Jan 10, 2014 at 9:56 PM, Florian Pritz wrote:
> Last but not least, it keeps the interface between "exec" and "lua"
> filters the same or at least rather similar. If you can call a lua
> script as if it was execed (setting argv) that would make the handler
> totally transparent, but faster
35 matches
Mail list logo
