From: Junio C Hamano Date: Tue, 27 Mar 2012 23:26:05 GMT Subject: Re: [PATCH/RFC v2 1/4] fetch-pack: new --stdin option to read refs from stdin Message-ID: <7vwr65y6b6.fsf@alter.siamese.dyndns.org> In-Reply-To: <4F724ADC.2030909@gmx.net> Ivan Todoroski writes: > On 27.03.2012 18:59, Junio C Hamano wrote: >> Ivan Todoroski 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. >> 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.