From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 14 Nov 2014 20:35:22 GMT
Subject: Re: Git archiving only branch work
Message-ID: <xmqq7fyx34hh.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20141114153222.GA23077@peff.net>

Jeff King <peff@peff.net> writes:

> On Thu, Nov 13, 2014 at 01:48:12PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> > I agree they are technically orthogonal, but I cannot think of a case
>> > where I have ever generated actual _pathspecs_, which might have
>> > wildcards, and needed to use "-z". The point of using "-z" is that you
>> > do not know what crap you are feeding.
>> 
>> You do not have to generate, i.e. you should be allowed to do this:
>> 
>>     $ git cmd --stdin -z <list-of-patterns
>
> Right. My point is that I am not sure anybody ever really _wants_ to do
> this, versus:
>
>   git cmd -- "$pattern1" "$pattern2"
>
> Because patterns tend to be small in number and made with predictable
> characters known to the script writer. It is sets of arbitrary filenames
> that tend to be long and contain random junk.

Perhaps "<filename" may have what made it confusing, as it made it
look as if the script writer has control over it (e.g. configuration
file).  The point actually was that the script invoking --stdin may
not even _know_ the number or the nature of patterns (e.g. end user
input).  Imagine a back-end that receives an RPC request from a
gitweb like front-end that lets you pick a tree and a set of
optional pathspecs, and continue below.

>> And this is not about "flexibility".  Unless your plan is to forbid
>> a corner case you do not anticipate and always disable pathspec
>> globbing, you would need to say something like:
>
> I had just assumed we would forbid,

That design is perfectly fine by me, actually.

I somehow hoped that "--stdin" is (uniformly across subcommands) a
mechanism to let us throw the remainder of what we would have liked
to place on the command line at the command but we couldn't
(e.g. because we feared that too many of them might overflow the
command line length limit) from the standard input stream instead.
As long as you are feeding pathspecs, we should uniformly treat them
as pathspecs no matter where they come from, either from the command
line or the standard input stream.  Special casing "--stdin" with or
without "-z" did not make sense to me in that mindset.

But existing use of "--stdin" is not necessarily "you can feed what
you would otherwise place on command line".  "hash-object --stdin"
is not about reading the name of path that contains the data to be
hashed (the option is "--stdin-path" there).  "update-index --stdin"
is sort of like that but different, in that the underlying command
does not take pathspec in the first place and it takes a "list of
paths" the same way from it takes them from the command line, which
makes it a bad comparison.

So I think "git archive --stdin [-z]" that takes list of paths, not
pathspec, is perfectly fine.