Junio C Hamano <gits...@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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
