On Sun, Jan 12, 2014 at 8:35 PM, John Keeping wrote:
> I'm looking at splitting up the data so there is a filter object that
> contains function pointers to implementation functions and then some
> data that is specific to to given filter type. With that change, cmd
> moves to the "exec filter" s
On Sun, Jan 12, 2014 at 08:23:02PM +0100, Jason A. Donenfeld wrote:
> What's the purpose of this? Why not just keep the original string that
> was passed to about-filter=... in the cmd variable as we have now? The
> thing that's variable from filter to filter is argv, the type (commit,
> about, etc
What's the purpose of this? Why not just keep the original string that
was passed to about-filter=... in the cmd variable as we have now? The
thing that's variable from filter to filter is argv, the type (commit,
about, etc), and the mechanism (lua, stdout, etc). But the variable
aspects don't requ
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
---
cgit.c | 6 +++---
cgit.h | 1 +
filter.c | 5 +
3 file