From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: "Git List" <git@vger.kernel.org>,
"Junio C Hamano" <gitster@pobox.com>,
"SZEDER Gábor" <szeder.dev@gmail.com>
Subject: Re: [PATCH v3 31/39] bundle: add new version for use with SHA-256
Date: Fri, 24 Jul 2020 01:11:28 +0000 [thread overview]
Message-ID: <20200724011127.GC1758454@crustytoothpaste.net> (raw)
In-Reply-To: <CAPig+cRWptYRJUpT71jW6_O9UZ1RK=FCbZj-+OkR_5kGqSWScg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2035 bytes --]
On 2020-07-23 at 05:31:15, Eric Sunshine wrote:
> Rather than having to worry about updating this each time the format
> changes, perhaps just say:
>
> A Git bundle consists of several parts.
Seems prudent. The reader probably doesn't care exactly how many parts
there are, and if they do, they can count for themselves.
> I wonder if it would be simpler and cleaner to do something like this instead:
>
> cat >expect <<\-EOF &&
> # v3 git bundle
> @object-format=sha256
> -[OID] message
> [OID] refs/head/master
>
> EOF
> head -n 5 "$D"/bundle1 | sanitize_oid >actual &&
> test_cmp expect actual
>
> where sanitize_oid() is a function which converts a hex OID into the
> literal string "[OID]" (or whatever). I believe I've seen you employ
> such sanitization functions already in these series in cases when you
> want to verify that an OID is present in some output but don't care
> about the actual value.
>
> Or perhaps this approach is overkill?
>
> Reading further in this patch, I see that you actually do employ this
> technique in a new test you add to t5607, though you don't bother with
> OID sanitation in that test.
Sure, I can do that.
> I worry about passing binary bundle data through 'sed' like this.
> Historically, some 'sed' implementations would drop the last part of a
> file if it didn't end with a newline. Even today, not all 'sed'
> implementations necessarily pass the binary data through unmolested.
> For instance, on Mac OS, 'sed' adds a newline at the end of the file
> if the binary bundle blob didn't end with a newline. Perhaps a more
> reliable approach would be to use Perl to read the entire bundle in as
> a blob, use s/// to munge the @object-format= line into the @unknown=
> line, and write it out.
Yeah, I was slightly worried about that, but as you mentioned in the
followup email, it's probably fine to just parse the header and verify
we reject that.
--
brian m. carlson: Houston, Texas, US
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2020-07-24 1:11 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 1:09 [PATCH v3 00/39] SHA-256, part 3/3 brian m. carlson
2020-07-23 1:09 ` [PATCH v3 01/39] t: make test-bloom initialize repository brian m. carlson
2020-07-23 1:09 ` [PATCH v3 02/39] t1001: use $ZERO_OID brian m. carlson
2020-07-23 1:09 ` [PATCH v3 03/39] t3305: make hash agnostic brian m. carlson
2020-07-23 1:09 ` [PATCH v3 04/39] t3404: prepare 'short SHA-1 collision' tests for SHA-256 brian m. carlson
2020-07-23 1:09 ` [PATCH v3 05/39] t6100: make hash size independent brian m. carlson
2020-07-23 1:09 ` [PATCH v3 06/39] t6101: " brian m. carlson
2020-07-23 1:09 ` [PATCH v3 07/39] t6301: " brian m. carlson
2020-07-23 1:09 ` [PATCH v3 08/39] t6500: specify test values for SHA-256 brian m. carlson
2020-07-23 1:09 ` [PATCH v3 09/39] t6501: avoid hard-coded objects brian m. carlson
2020-07-23 1:09 ` [PATCH v3 10/39] t7003: compute appropriate length constant brian m. carlson
2020-07-23 1:09 ` [PATCH v3 11/39] t7063: make hash size independent brian m. carlson
2020-07-23 1:09 ` [PATCH v3 12/39] t7201: abstract away SHA-1-specific constants brian m. carlson
2020-07-23 1:09 ` [PATCH v3 13/39] t7102: " brian m. carlson
2020-07-23 1:09 ` [PATCH v3 14/39] t7400: make hash size independent brian m. carlson
2020-07-23 1:09 ` [PATCH v3 15/39] t7405: " brian m. carlson
2020-07-23 1:09 ` [PATCH v3 16/39] t7506: avoid checking for SHA-1-specific constants brian m. carlson
2020-07-23 1:09 ` [PATCH v3 17/39] t7508: use $ZERO_OID instead of hard-coded constant brian m. carlson
2020-07-23 1:09 ` [PATCH v3 18/39] t8002: make hash size independent brian m. carlson
2020-07-23 1:09 ` [PATCH v3 19/39] t8003: " brian m. carlson
2020-07-23 1:09 ` [PATCH v3 20/39] t8011: " brian m. carlson
2020-07-23 1:09 ` [PATCH v3 21/39] t9300: abstract away SHA-1-specific constants brian m. carlson
2020-07-23 1:09 ` [PATCH v3 22/39] t9300: use $ZERO_OID instead of hard-coded object ID brian m. carlson
2020-07-23 1:09 ` [PATCH v3 23/39] t9301: make hash size independent brian m. carlson
2020-07-23 1:09 ` [PATCH v3 24/39] t9350: " brian m. carlson
2020-07-23 1:09 ` [PATCH v3 25/39] t9500: ensure that algorithm info is preserved in config brian m. carlson
2020-07-23 1:09 ` [PATCH v3 26/39] t9700: make hash size independent brian m. carlson
2020-07-23 1:09 ` [PATCH v3 27/39] t5308: make test work with SHA-256 brian m. carlson
2020-07-23 1:09 ` [PATCH v3 28/39] t0410: mark test with SHA1 prerequisite brian m. carlson
2020-07-23 1:09 ` [PATCH v3 29/39] http-fetch: set up git directory before parsing pack hashes brian m. carlson
2020-07-23 1:09 ` [PATCH v3 30/39] builtin/verify-pack: implement an --object-format option brian m. carlson
2020-07-23 4:54 ` Eric Sunshine
2020-07-23 1:09 ` [PATCH v3 31/39] bundle: add new version for use with SHA-256 brian m. carlson
2020-07-23 5:31 ` Eric Sunshine
2020-07-23 5:40 ` Eric Sunshine
2020-07-24 1:11 ` brian m. carlson [this message]
2020-07-23 1:09 ` [PATCH v3 32/39] setup: add support for reading extensions.objectformat brian m. carlson
2020-07-23 2:04 ` Junio C Hamano
2020-07-23 2:39 ` brian m. carlson
2020-07-23 4:15 ` Junio C Hamano
2020-07-25 1:59 ` brian m. carlson
2020-07-23 1:09 ` [PATCH v3 33/39] Enable SHA-256 support by default brian m. carlson
2020-07-23 1:09 ` [PATCH v3 34/39] t: add test_oid option to select hash algorithm brian m. carlson
2020-07-23 4:51 ` Eric Sunshine
2020-07-23 23:38 ` brian m. carlson
2020-07-23 23:46 ` Eric Sunshine
2020-07-24 0:05 ` Junio C Hamano
2020-07-23 1:09 ` [PATCH v3 35/39] t: allow testing different hash algorithms via environment brian m. carlson
2020-07-23 1:09 ` [PATCH v3 36/39] t: make SHA1 prerequisite depend on default hash brian m. carlson
2020-07-23 1:09 ` [PATCH v3 37/39] ci: run tests with SHA-256 brian m. carlson
2020-07-23 1:09 ` [PATCH v3 38/39] docs: add documentation for extensions.objectFormat brian m. carlson
2020-07-23 1:09 ` [PATCH v3 39/39] t: remove test_oid_init in tests brian m. carlson
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=20200724011127.GC1758454@crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sunshine@sunshineco.com \
--cc=szeder.dev@gmail.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 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.