Re: Simplify-by-decoration with decorate-refs-exclude

From: René Scharfe <l.s.r@web.de>
Date: Aug 2, 2019, 20:36 UTC
Message-ID: <5de287e9-a8e8-780a-7d39-2229b61914ca@web.de>
In-Reply-To: <xmqq36ijl6qu.fsf@gitster-ct.c.googlers.com>

Am 02.08.19 um 21:14 schrieb Junio C Hamano:

> I can see how this would help, but it somehow feels a bit brittle
> to rely on where the decorations get loaded.

Right.

Show 7 quoted lines

> I wonder if it would help to move the ability to handle decoration
> filter down from the log layer to revisions.c API layer.
>
> It looks to me that this caller of setup_revisions() can prepare
> decoration_filter before it calls setup_revisions(); we can let the
> revisions.c layer call load_ref_decorations() in setup_revisions()
> if that is the case, no?

Having cmd_log_init_finish() call load_ref_decorations() before setup_revisions() would indeed solve the issue as well. But we need to call the latter to check if --pretty=raw was given and avoid loading decorations in that case, don't we?

> Other two callers of load_ref_decorations() are deep inside pretty.c
> but I wonder in the longer term if we would want to turn them into
> an "a lot higher level should have already loaded decorations"
> assert.

This would require that higher level to parse the user format to check if %d or %D is present before formatting the first item. Hmm.

René