Re: [PATCH v6 0/10] port tag.c to use ref-filter APIs
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 29, 2015, 20:29 UTC
- Message-ID
- <xmqqbneu907l.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <CAPig+cQv4BWFwgx7mDHh=gNpxbEeR7auw4os-tOpf3cGah=zpw@mail.gmail.com>
Eric Sunshine <sunshine@sunshineco.com> writes:
Show 8 quoted lines
>> 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).