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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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é




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux