From: Ivan Todoroski <grnch@gmx.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, Shawn Pearce <spearce@spearce.org>,
Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
Jakub Narebski <jnareb@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH/RFC v2 1/4] fetch-pack: new --stdin option to read refs from stdin
Date: Wed, 28 Mar 2012 01:18:52 +0200 [thread overview]
Message-ID: <4F724ADC.2030909@gmx.net> (raw)
In-Reply-To: <7vhaxaj7yi.fsf@alter.siamese.dyndns.org>
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?
>> + }
>> + }
>> + else {
>> + /* read from stdin one ref per line, until EOF */
>> + struct strbuf line;
>> + strbuf_init(&line, 0);
>> + for (;;) {
>> + if (strbuf_getline(&line, stdin, '\n') == EOF)
>> + break;
>> + strbuf_trim(&line);
>> + if (!line.len)
>> + continue; /* skip empty 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 which could leave some whitespace here and there,
so a more liberal interface might be more friendly to such script writers.
Currently you would pass a list of generated refs to fetch-pack using
something like this:
generate-refs | xargs fetch-pack
or this:
fetch-pack $(generate-refs)
Both of these commands will ignore any extra whitespace produced by
"generate-refs".
Since --stdin is meant to be a spiritual replacement for the two
commands above, I thought it should behave in a similar spirit.
At least that was the reasoning... if you're not swayed by it I can just
remove those lines and not tolerate any extra whitespace.
next prev parent reply other threads:[~2012-03-27 23:18 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-18 8:14 Clone fails on a repo with too many heads/tags Ivan Todoroski
2012-03-18 11:37 ` Ivan Todoroski
2012-03-18 12:04 ` Nguyen Thai Ngoc Duy
2012-03-18 16:36 ` Jakub Narebski
2012-03-18 19:07 ` Jeff King
2012-03-18 22:07 ` Jakub Narebski
2012-03-19 2:32 ` Jeff King
2012-03-19 2:43 ` Nguyen Thai Ngoc Duy
2012-03-19 2:45 ` Jeff King
2012-03-19 1:05 ` Ivan Todoroski
2012-03-19 1:30 ` Nguyen Thai Ngoc Duy
2012-03-19 2:44 ` Jeff King
2012-03-21 11:05 ` Ivan Todoroski
2012-03-21 14:28 ` Shawn Pearce
2012-03-21 17:14 ` Jeff King
2012-03-21 17:59 ` Jakub Narebski
2012-03-21 20:02 ` Ivan Todoroski
2012-03-21 20:17 ` Jeff King
2012-03-24 20:49 ` Ivan Todoroski
2012-03-25 1:06 ` Jeff King
2012-03-25 2:32 ` Jeff King
2012-03-25 17:33 ` Ivan Todoroski
2012-03-25 17:54 ` Ivan Todoroski
2012-03-26 17:33 ` Jeff King
2012-03-27 7:07 ` Ivan Todoroski
2012-03-25 15:30 ` Ivan Todoroski
2012-03-24 20:53 ` [PATCH/RFC 1/2] fetch-pack: new option to read refs from stdin Ivan Todoroski
2012-03-25 1:19 ` Jeff King
2012-03-25 9:39 ` Ivan Todoroski
2012-03-25 15:15 ` Ivan Todoroski
2012-03-25 20:00 ` Ivan Todoroski
2012-03-26 17:21 ` Jeff King
2012-03-26 17:49 ` Ivan Todoroski
2012-03-26 17:51 ` Jeff King
2012-03-24 20:54 ` [PATCH/RFC 2/2] remote-curl: send the refs to fetch-pack on stdin Ivan Todoroski
2012-03-25 1:24 ` Jeff King
2012-03-25 9:52 ` Ivan Todoroski
2012-03-26 17:24 ` Jeff King
2012-03-27 6:23 ` [PATCH/RFC v2 0/4] Fix fetch-pack command line overflow during clone Ivan Todoroski
2012-03-27 6:25 ` [PATCH/RFC v2 1/4] fetch-pack: new --stdin option to read refs from stdin Ivan Todoroski
2012-03-27 16:59 ` Junio C Hamano
2012-03-27 23:18 ` Ivan Todoroski [this message]
2012-03-27 23:26 ` Junio C Hamano
2012-03-27 23:48 ` Ivan Todoroski
2012-03-27 6:26 ` [PATCH/RFC v2 2/4] remote-curl: send the refs to fetch-pack on stdin Ivan Todoroski
2012-03-27 17:18 ` Junio C Hamano
2012-03-27 23:20 ` Ivan Todoroski
2012-03-27 6:27 ` [PATCH/RFC v2 3/4] fetch-pack: test cases for the new --stdin option Ivan Todoroski
2012-03-27 17:40 ` Junio C Hamano
2012-03-27 23:36 ` Ivan Todoroski
2012-03-27 23:43 ` Junio C Hamano
2012-03-28 0:14 ` Ivan Todoroski
2012-03-27 6:28 ` [PATCH/RFC v2 4/4] remote-curl: main test case for the OS command line overflow Ivan Todoroski
2012-03-27 17:43 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F724ADC.2030909@gmx.net \
--to=grnch@gmx.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).