In the commit introducing this code ([1]), I wrote a typo such that the
'git config' invocation changed did not apply 'contenttype=0' to the API
call executed by 'git push origin master'.
So, when I copied and pasted this test case from the one above, I didn't
change the '1' to a '0', because when I ran 'make -B t-content-type.sh',
the test passed.
This commit fixes the incorrect spelling in 'git config' and updates the
assertion to pass, and confirms that setting a 'contenttype' to '0'
disables content-type detection.
[1]: 938df5c4 (tq/basic_upload.go: disable Content-Type detection by
configuration, 2018-07-31)
For the majority of Git LFS's lifetime, Git LFS objects have been
uploaded via HTTP and contained the header:
Content-Type: application/octet-stream
In [1], this changed and we began attempting to guess an appropriate
Content-Type header based on the first 512 bytes of the file being
uploaded.
This breaks some hosting platforms' implementation of this API, so let's
offer a way to disable this guessing to allow users to upload objects
again on affected implementations.
[1]: a1736293 (Merge pull request #3137 from
calavera/set_upload_content_type, 2018-07-23)
