Re: [PATCH 08/10] cat-file: split --batch input lines on whitespace

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 11, 2013, 17:42 UTC
Message-ID: <7vvc4hq9hs.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130711113653.GD6015@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 24 quoted lines

> On Wed, Jul 10, 2013 at 08:59:51PM +0530, Ramkumar Ramachandra wrote:
>
>> Jeff King wrote:
>> >   git rev-list --objects HEAD |
>> >   git cat-file --batch-check='%(objectsize) %(text)'
>> 
>> If anything, I would have expected %(rest), not %(text).  This atom is
>> specific to commands that accept input via stdin (i.e. not log, f-e-r,
>> branch, or anything else I can think of).
>
> I considered %(rest) as well. I don't have a strong preference.
>
>> Also, this makes me wonder if %(field:0), %(field:1), and probably
>> %(field:@) are good ideas.  Even if we go down that road, I don't
>> think %(rest) is a problem per-se.
>
> I don't have a use for them, and even if we want to add them later, you
> would still want to support %(rest) for when the user wants to take the
> rest of the line verbatim without caring about field-splitting.
>
> To be honest, I do not see %(field) as all that useful. If you want to
> go about rearranging or selecting fields, that is what "cut" (or "awk")
> is for.  Having fields means you need to specify field separators, and
> how runs of separators are treated. Other tools already do this.

Very true, and more importantly, you cannot still say "my input object name is at field N, not at the beginning", so that makes it doubly dubious how %(field:$n) would be any useful.

> So it would (at best) save you from an extra cut invocation, whereas
> %(rest) gets you out of doing something much more difficult. Without it,
> information is lost from your pipeline (so you have to have tee to a
> separate pipeline, and then reassemble the pieces).