Re: [PATCH v7 13/17] ref-filter: add `:dir` and `:base` options for ref printing atoms

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 15, 2016, 17:42 UTC
Message-ID: <xmqq4m38vdw4.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CA+P7+xo6OqcpLZ7v_m1EPm85eK2xCPD_LCw1Ly2RSPeSC0Ei7g@mail.gmail.com>

Jacob Keller <jacob.keller@gmail.com> writes:

Show 6 quoted lines

> dirname makes sense. What about implementing a reverse variant of
> strip, which you could perform stripping of right-most components and
> instead of stripping by a number, strip "to" a number, ie: keep the
> left N most components, and then you could use something like
> ...
> I think that would be more general purpose than basename, and less confusing?

I think you are going in the right direction. I had a similar thought but built around a different axis. I.e. if strip=1 strips one from the left, perhaps we want to have rstrip=1 that strips one from the right, and also strip=-1 to mean strip everything except one from the left and so on?. I think this and your keep (and perhaps you'll have rkeep for completeness) have the same expressive power. I do not offhand have a preference one over the other.

Somehow it sounds a bit strange to me to treat 'remotes' as the same class of token as 'heads' and 'tags' (I'd expect 'heads' and 'remotes/origin' would be at the same level in end-user's mind), but that is probably an unrelated tangent. The reason this series wants to introduce :base must be to emulate an existing feature, so that existing feature is a concrete counter-example that argues against my "it sounds a bit strange" reaction.