Re: [PATCH v6 0/10] port tag.c to use ref-filter APIs

[Junio C Hamano <gitster@pobox.com>]

Eric Sunshine <sunshine@sunshineco.com> writes:

>> Side Note: --format="%(padright:X)" applies to the next available atom
>> and not to the next span. I find this more accurate as I don't see why
>> we'd want to pad something of known length. But its up for discussion
>
> This isn't supported by the current %(padright:) syntax, but an
> example would be if someone wants to pad a string composed of atoms
> and literal strings. For instance, the user might want to right-pad
> the composed string "%(refattribute1) glorked %(refattribute2)”.

It is an excellent example that shows why "something of known
length" argument needs to be rethought.

"Currently we do not need it to reimplement the canned 'tag -l'
format" is an OK and sensible justification to stick to the current
implementation of %(padright:N), but we'd need to think if we would
want to keep this limited and strange form that applies to a single
atom that comes next (ignoring any literal spans) as a private
implementation detail between ref-filter and "git tag".  Opening it
up to end-users would not mean we cannot add a correctly operating
variant of "pad this string to the right" later, but it does mean we
have to maintain %(padright) in this limited form forever.

My knee-jerk reaction is that we probably should not want to expose
this to the end users, and to discourage its use, perhaps name it
somewhat strangely (e.g. "%(x-padright:N)" or something).