List for cgit developers and users
 help / color / mirror / Atom feed
From: john at keeping.me.uk (John Keeping)
Subject: [PATCH] ui-tree.c: check source filter if set globally
Date: Wed, 30 Jul 2014 20:23:21 +0100	[thread overview]
Message-ID: <20140730192321.GJ26927@serenity.lan> (raw)
In-Reply-To: <1406746401-24187-1-git-send-email-jamie.couture@gmail.com>

On Wed, Jul 30, 2014 at 02:53:21PM -0400, Jamie Couture wrote:
> When parsing cgitrc users that place 'source-filter' setting after
> 'scan-path' find their source filter is never run.
> 
>   scan-path=/home/git/repositories
>   source-filter=/usr/local/lib/cgit/filters/syntax-highlighting.sh
> 
> ui-tree.c will print out our repository objects, but will only consider
> ctx.repo->source_filter struct and not checking ctx.cfg.source_filter
> 
> The value would have been set in shared.c, via cgit_add_repo() but this
> isn't the case when using scan-path, because we have not yet processed
> the source-filter line in our cgitrc, and thus the source_filter struct
> will not be initialized.
> 
> Checking the global configuration in ui-tree.c is necessary to avoid an
> issue where users declare the source filter after scan-path.

I think this is OK because we only fall back if repo->source_filter is
unset and there is no way to unset the source filter for a repository
AFAICT.  But if we do this for source-filter, why not also about-filter,
email-filter and commit-filter?

The documentation already makes it clear that settings should be
configured before "scan-path", and scan-path isn't special here you
could equally well demonstrate the same effect with:

	repo.url=my-repository
	source-filter=/path/to/source-filter.sh

I'm not convinced that this change makes things less confusing, it just
means that "everything except source-filter must be configured before
adding repositories", which seems more confusing.

The full list of captured settings is:

	ret->section = ctx.cfg.section;
	ret->snapshots = ctx.cfg.snapshots;
	ret->enable_commit_graph = ctx.cfg.enable_commit_graph;
	ret->enable_log_filecount = ctx.cfg.enable_log_filecount;
	ret->enable_log_linecount = ctx.cfg.enable_log_linecount;
	ret->enable_remote_branches = ctx.cfg.enable_remote_branches;
	ret->enable_subject_links = ctx.cfg.enable_subject_links;
	ret->max_stats = ctx.cfg.max_stats;
	ret->branch_sort = ctx.cfg.branch_sort;
	ret->commit_sort = ctx.cfg.commit_sort;
	ret->module_link = ctx.cfg.module_link;
	ret->readme = ctx.cfg.readme;
	ret->about_filter = ctx.cfg.about_filter;
	ret->commit_filter = ctx.cfg.commit_filter;
	ret->source_filter = ctx.cfg.source_filter;
	ret->email_filter = ctx.cfg.email_filter;
	ret->clone_url = ctx.cfg.clone_url;

And I don't think we want to change all of these to allow the config
file to be out-of-order.

Perhaps we would be better off making the documentation clearer rather
than trying to fix some particular cases?

> Signed-off-by: Jamie Couture <jamie.couture at gmail.com>
> ---
>  ui-tree.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/ui-tree.c b/ui-tree.c
> index e4c3d22..f52f15c 100644
> --- a/ui-tree.c
> +++ b/ui-tree.c
> @@ -22,6 +22,7 @@ static void print_text_buffer(const char *name, char *buf, unsigned long size)
>  {
>  	unsigned long lineno, idx;
>  	const char *numberfmt = "<a id='n%1$d' href='#n%1$d'>%1$d</a>\n";
> +	struct cgit_filter *source_filter = NULL;
>  
>  	html("<table summary='blob content' class='blob'>\n");
>  
> @@ -45,11 +46,17 @@ static void print_text_buffer(const char *name, char *buf, unsigned long size)
>  	}
>  
>  	if (ctx.repo->source_filter) {
> +		source_filter = ctx.repo->source_filter;
> +	} else if (ctx.cfg.source_filter) {
> +		source_filter = ctx.cfg.source_filter;
> +	}
> +
> +	if (source_filter) {
>  		char *filter_arg = xstrdup(name);
>  		html("<td class='lines'><pre><code>");
> -		cgit_open_filter(ctx.repo->source_filter, filter_arg);
> +		cgit_open_filter(source_filter, filter_arg);
>  		html_raw(buf, size);
> -		cgit_close_filter(ctx.repo->source_filter);
> +		cgit_close_filter(source_filter);
>  		free(filter_arg);
>  		html("</code></pre></td></tr></table>\n");
>  		return;
> -- 
> 1.9.1.377.g96e67c8
> 
> _______________________________________________
> CGit mailing list
> CGit at lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/cgit


  reply	other threads:[~2014-07-30 19:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-28 21:14 source-filter isn't getting applied njn2118
2014-07-28 22:38 ` john
     [not found]   ` <CA+TJm37SY1PwBuYgTpn=bQz0D7LcGdwwSZb=38ZbHK_DX1j5JA@mail.gmail.com>
2014-07-29  3:59     ` Fwd: " njn2118
2014-07-29  7:37       ` john
2014-07-30  4:17         ` njn2118
2014-07-30  4:21           ` njn2118
2014-07-30  7:57           ` john
2014-07-30 18:53 ` [PATCH] ui-tree.c: check source filter if set globally jamie.couture
2014-07-30 19:23   ` john [this message]
2014-07-30 20:47     ` jamie.couture
2014-07-30 21:06       ` jamie.couture
2014-07-30 21:14       ` john
2014-07-31  1:05         ` jamie.couture
2014-07-31  1:08           ` jamie.couture
2014-08-01 15:38             ` Jason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140730192321.GJ26927@serenity.lan \
    --to=cgit@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).