Commit _subject_ filter, everywhere
john at keeping.me.uk
Sat Dec 2 13:49:16 CET 2017
On Sat, Dec 02, 2017 at 01:33:28PM +0100, Bjjjrn Forsman wrote:
> On 2 December 2017 at 12:31, John Keeping <john at keeping.me.uk> wrote:
> > I was going to suggest introducing a new subject-filter which is used to
> > filter the commit subject wherever it is displayed, but there is a
> > subtlety which makes this more complicated in the summary, log and refs
> > pages than it is in the commit page.
> > When we are showing a single-line summary of a commit, the subject is a
> > hyperlink so adding new content outside the existing subject is not
> > possible with the obvious filter implementation.
> > One option would be to push the <a></a> tag generation down into the
> > filter, but I'd rather avoid that if possible.
> Aha, I see.
After I wrote that I realised that for the existing commit-filter we
escape the content before writing to the filter. So it might be
reasonable to pass the whole <a></a> tag through the filter.
That would make it easy for the filter to put extra content either
before or after the commit subject. It also makes the filter
integration much simpler, for example in ui-log.c:
-- >8 --
diff --git a/ui-log.c b/ui-log.c
index 2d2bb31..f2a7852 100644
@@ -234,8 +234,11 @@ static void print_commit(struct commit *commit, struct rev_info *revs)
strcpy(info->subject + i, wrap_symbol);
cgit_commit_link(info->subject, NULL, NULL, ctx.qry.head,
cgit_open_filter(ctx.repo->email_filter, info->author_email, "log");
-- 8< --
> > What do you think about adding a "filter" which is called before the
> > commit subject is printed and allows outputting additional HTML content?
> > ("filter" is in quotes since there will not be any content copied
> > through the program.)
> Sounds good to me. It covers my use case.
> Perhaps this new "filter" should not have filter in its name.
> Suggestion: commit-prefix=.
> Oh, and this new command must somehow receive the commit id from cgit.
> New environment variable?
We normally use arguments for this, which is all handled via the
I expect Lua filters may be preferred for this use case to avoid forking
50 child processes when displaying the log view.
More information about the CGit