From: Junio C Hamano <gitster@pobox.com>
To: Adam Roben <aroben@apple.com>
Cc: git@vger.kernel.org, Brian Downing <bdowning@lavos.net>
Subject: Re: [PATCH 4/9] git-cat-file: Add --stdin option
Date: Fri, 26 Oct 2007 13:59:24 -0700 [thread overview]
Message-ID: <7vd4v1y4lv.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 1193307927-3592-5-git-send-email-aroben@apple.com
Adam Roben <aroben@apple.com> writes:
> @@ -23,6 +23,10 @@ OPTIONS
> For a more complete list of ways to spell object names, see
> "SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
>
> +--stdin::
> + Read object names from stdin instead of specifying one on the
> + command line.
> +
This does not talk about modified output format: what the format
is, nor when that modified format is used.
> @@ -139,16 +139,26 @@ static int cat_one_file(int opt, const char *exp_type, const char *obj_name)
> if (!buf)
> die("git-cat-file %s: bad file", obj_name);
>
> + if (print_size) {
> + printf("%lu\n", size);
> + fflush(stdout);
> + }
> write_or_die(1, buf, size);
> + if (print_size) {
> + printf("\n");
> + fflush(stdout);
> + }
> return 0;
> }
>
Not that I object strongly to it, but do we need extra LF after
the contents?
- "It would help readers written in typical scripting
languages" is an acceptable answer, but I doubt that is the
case --- the reader is given the number of bytes and is
going to "read($pipe, $buf, $that_size)" anyway.
- "The reader can assert that one-byte past the content is a
LF to catch errors, and this LF would help re-synchronize
after such an error" would be another acceptable answer, but
for the re-synchronization to work, the output needs to tell
which record each chunk is about (i.e. if the output were
"<type> <sha1> <size>LF<contents>LF", the "re-sync" argument
would make a bit more sense).
> + print_size = !opt || opt == 'p';
Needs a bit of comment here, and in the documentation. E.g.
git-cat-file --stdin -t <list-of-sha1
git-cat-file --stdin -s <list-of-sha1
are ways to check types and sizes of the objects in the
list.
How does --stdin interact with -e?
How does --stdin interact with -p when printing a tree or a tag
object?
How does "blob --stdin" do when input sequence contains a non
blob SHA1?
It almost feels that --stdin should be named something else,
such as --batch or --bulk, as it is not just affecting the
input.
Here is an alternative suggestion.
Two new options, --batch and --batch-check, are introduced.
These options are incompatible with -[tsep] or an object type
given as the first parameter to git-cat-file.
* git-cat-file --batch-check <list-of-sha1
outputs a record of this form
<sha1> SP <type> SP <size> LF
for each of the input lines.
* git-cat-file --batch <list-of-sha1
outputs a record of this form
<sha1> SP <type> SP <size> LF <contents> LF
for each of the input lines.
For a missing object, either option gives a record of form:
<sha1> SP missing LF
next prev parent reply other threads:[~2007-10-26 20:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-25 10:25 [RESEND PATCH 0/9] Make git-svn fetch ~1.7x faster Adam Roben
2007-10-25 10:25 ` [PATCH 1/9] Add tests for git cat-file Adam Roben
2007-10-25 10:25 ` [PATCH 2/9] git-cat-file: Small refactor of cmd_cat_file Adam Roben
2007-10-25 10:25 ` [PATCH 3/9] git-cat-file: Make option parsing a little more flexible Adam Roben
2007-10-25 10:25 ` [PATCH 4/9] git-cat-file: Add --stdin option Adam Roben
2007-10-25 10:25 ` [PATCH 5/9] Add tests for git hash-object Adam Roben
2007-10-25 10:25 ` [PATCH 6/9] git-hash-object: Add --stdin-paths option Adam Roben
2007-10-25 10:25 ` [PATCH 7/9] Git.pm: Add command_bidi_pipe and command_close_bidi_pipe Adam Roben
2007-10-25 10:25 ` [PATCH 8/9] Git.pm: Add hash_and_insert_object and cat_blob Adam Roben
2007-10-25 10:25 ` [PATCH 9/9] git-svn: Make fetch ~1.7x faster Adam Roben
2007-10-26 15:11 ` [PATCH 8/9] Git.pm: Add hash_and_insert_object and cat_blob Eric Wong
2007-10-26 21:00 ` [PATCH 6/9] git-hash-object: Add --stdin-paths option Junio C Hamano
2007-10-26 23:19 ` Brian Downing
2007-10-27 1:02 ` Junio C Hamano
2007-10-26 21:00 ` [PATCH 5/9] Add tests for git hash-object Junio C Hamano
2007-10-26 20:59 ` Junio C Hamano [this message]
2007-10-26 20:56 ` [PATCH 3/9] git-cat-file: Make option parsing a little more flexible Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2007-10-23 5:46 [PATCH 0/9] Make git-svn fetch ~1.7x faster Adam Roben
2007-10-23 5:46 ` [PATCH 1/9] Add tests for git cat-file Adam Roben
2007-10-23 5:46 ` [PATCH 2/9] git-cat-file: Small refactor of cmd_cat_file Adam Roben
2007-10-23 5:46 ` [PATCH 3/9] git-cat-file: Make option parsing a little more flexible Adam Roben
2007-10-23 5:46 ` [PATCH 4/9] git-cat-file: Add --stdin option Adam Roben
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=7vd4v1y4lv.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=aroben@apple.com \
--cc=bdowning@lavos.net \
--cc=git@vger.kernel.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).