Re: Git archiving only branch work

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 14, 2014, 20:35 UTC
Message-ID: <xmqq7fyx34hh.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20141114153222.GA23077@peff.net>

Jeff King <peff@peff.net> writes:

Show 21 quoted lines

> 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.

Show 5 quoted lines

>> 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.