Re: [PATCH/RFC v2 1/4] fetch-pack: new --stdin option to read refs from stdin

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 27, 2012, 23:26 UTC
Message-ID: <7vwr65y6b6.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4F724ADC.2030909@gmx.net>

Ivan Todoroski <grnch@gmx.net> writes:

Show 16 quoted lines

> On 27.03.2012 18:59, Junio C Hamano wrote:
>> Ivan Todoroski <grnch@gmx.net> writes:
>>
>>> +		int alloc_heads = nr_heads;
>>> +		int size = nr_heads * sizeof(*heads);
>>> +		heads = memcpy(xmalloc(size), heads, size);
>>> +		if (args.stateless_rpc) {
>>> +			/* in stateless RPC mode we use pkt-line to read
>>> +			   from stdin, until we get a flush packet */
>>> +			static char line[1000];
>>
>> We will never have a refname that is longer than this limit?
>
> I don't know. I grepped the code for existing usages of packet_read_line
> and that seemed to be a common idiom everywhere. Should I just bump up
> the size or is there some accepted way to read arbitrary length packets?

As you may have already guessed, you can have up to (64k - slop) bytes in a packet. But it probably does not matter, as a loong ref that bust your limit will not fit in the packet used in the normal codepath anyway.

Show 7 quoted lines

>> Curious.  "stop at EOF", "trim" and "skip empty" imply that you are
>> catering to people who debug this from the terminal by typing (or copy
>> pasting).  Is that the expected use case?
>
> The expected use case is people using this from shell scripts that
> could be getting refs by slicing and dicing output of other commands
> with regexps and what not

That kind of use would not have leading or trailing whitespaces, and if the target audience is scripts, I would prefer to force them to be strict.