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

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

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).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/