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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.