From: Junio C Hamano <gitster@pobox.com>
To: bdowning@lavos.net (Brian Downing)
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:02:05 -0700 [thread overview]
Message-ID: <7vlk9pv08i.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20071026231902.GC2519@lavos.net> (Brian Downing's message of "Fri, 26 Oct 2007 18:19:02 -0500")
bdowning@lavos.net (Brian Downing) writes:
> 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")?
Yeah, you caught me ;-)
Either making it optional or requiring a dummy value would work.
If a non-dummy value is given, we could use it to validate it.
But that would not be a useful application anyway. So perhaps
just the sequence of "<type> SP <size> LF <contents> LF" would
be the most sensible thing to do.
next prev parent reply other threads:[~2007-10-27 1:02 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
2007-10-27 1:02 ` Junio C Hamano [this message]
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=7vlk9pv08i.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).