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

> Junio C Hamano <gitster@pobox.com> writes:
>
>> "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).
>
> I disagree. The current %(padright) fits 99.9% needs. It's handy for the
> user if he wants a column-display with --format. It's consistant with
> the "git log" %<() atoms.
>
> Sure, if the user wants really advanced formatting, it's not sufficient.
> But first I believe this is a case of YAGNI, "right-pad an arbitrary
> string" is a funny coding exercice, but not very useful in real-life.
> And then, if one really has a use-case for advanced formatting, I think
> a much better approach is to dump an easy-to-parse language
> (XML/JSON/CSV/...) and pipe it to a formatter written in a real
> programming language. It will always be more powerful than having to
> chose in a limited set of %(atoms).
>