From: bdowning@lavos.net (Brian Downing)
To: Junio C Hamano <gitster@pobox.com>
Cc: Adam Roben <aroben@apple.com>, git@vger.kernel.org
Subject: Re: [PATCH 6/9] git-hash-object: Add --stdin-paths option
Date: Fri, 26 Oct 2007 18:19:02 -0500 [thread overview]
Message-ID: <20071026231902.GC2519@lavos.net> (raw)
In-Reply-To: <7vy7dpwpz4.fsf@gitster.siamese.dyndns.org>
On Fri, Oct 26, 2007 at 02:00:47PM -0700, Junio C Hamano wrote:
> In addition, if you are enhancing cat-file to spew chunked
> output out, I suspect that there should be a mode of operation
> for hash-object that eats that data format. IOW, this pipe
>
> git-cat-file --batch <list-of-sha1 |
> git-hash-object --batch
>
> should be an intuitive no-op, shouldn't it?
I think that's an obviously good thing to do. However, given your
suggested output format (which I also like):
> * 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.
What should the input behavior be? Obviously the sha1 will probably
not be known on the input side. Should that simply be optional (i.e.
it will accept either "<sha1> SP <type> SP <size>" or "<type> SP <size>"
or should it only accept the latter, and a dummy sha1 will need to be
filled in if the sha1 is not known (presumably "000...000")?
-bcd
next prev parent reply other threads:[~2007-10-26 23:19 UTC|newest]
Thread overview: 17+ 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 [this message]
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 ` [PATCH 4/9] git-cat-file: Add --stdin option Junio C Hamano
2007-10-26 20:56 ` [PATCH 3/9] git-cat-file: Make option parsing a little more flexible 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=20071026231902.GC2519@lavos.net \
--to=bdowning@lavos.net \
--cc=aroben@apple.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).