From: Matthieu Moy Date: Thu, 30 Jul 2015 09:44:52 GMT Subject: Re: [PATCH v6 0/10] port tag.c to use ref-filter APIs Message-ID: In-Reply-To: Junio C Hamano 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/