Re: [PATCH 20/44] t5562: pass object-format in synthesized test data
- From
- Martin Ågren <martin.agren@gmail.com>
- Date
- May 16, 2020, 10:55 UTC
- Message-ID
- <CAN0heSqVrOTpSpptqe+zu+9-qQVYAL=jcx7tas3pNRcSVH+auQ@mail.gmail.com>
- In-Reply-To
- <20200513005424.81369-21-sandals@crustytoothpaste.net>
On Wed, 13 May 2020 at 02:56, brian m. carlson <sandals@crustytoothpaste.net> wrote:
> > Ensure that we pass the object-format capability in the synthesized test > data so that this test works with algorithms other than SHA-1.
Right.
> In addition, add an additional test using the old data for when we're > using SHA-1 so that we can be sure that we preserve backwards > compatibility with servers not offering the object-format capability.
I'll have some questions on this below.
Show 11 quoted lines
> @@ -62,8 +63,8 @@ test_expect_success 'setup' '
> test_copy_bytes 10 <fetch_body >fetch_body.trunc &&
> hash_next=$(git commit-tree -p HEAD -m next HEAD^{tree}) &&
> {
> - printf "%s %s refs/heads/newbranch\\0report-status\\n" \
> - "$ZERO_OID" "$hash_next" | packetize &&
> + printf "%s %s refs/heads/newbranch\\0report-status object-format=%s\\n" \
> + "$ZERO_OID" "$hash_next" "$(test_oid algo)" | packetize &&
> printf 0000 &&
> echo "$hash_next" | git pack-objects --stdout
> } >push_body &&Makes sense.
Show 13 quoted lines
> @@ -117,6 +118,15 @@ test_expect_success GZIP 'push plain' ' > test_cmp act.head exp.head > ' > > +test_expect_success GZIP 'push plain with SHA-1' ' > + test_when_finished "git branch -D newbranch" && > + test_http_env receive push_body && > + verify_http_result "200 OK" && > + git rev-parse newbranch >act.head && > + echo "$hash_next" >exp.head && > + test_cmp act.head exp.head > +' > +
Hmmm. Isn't this an exact copy of the 'push plain' test immediately preceding it? The commit message talks about using the "old data" (i.e., without "object-format=%s"?). Should this test use a variant of push_body where we're not adding "object-format"? I'm not sure I grok what exactly we want to test here.. And does it really belong in t/t*-content-length.sh?
Martin