Currently, our default branch in tests is "master". This is the Git
default, but the Git default will likely change in the future, so it
makes sense to update our testsuite to be explicit about the branch
name. We'll ensure this continues by building against older versions of
Git as well as newer versions.
We use "main" for the new branch name, since that's the proposed value
upstream.
This commit was made entirely by automated means using the following
command:
git grep -l master t | xargs sed -i -e 's/master/main/g'
As of v2.5.1, we provide an option to disable automatic detection of the
Content-Type and always use application/octet-stream instead. However,
when that option is set, instead of providing a Content-Type of
application/octet-stream, we fail to provide one at all.
Ensure that we always set some Content-Type header when uploading files
by skipping the detection but preserving the fallback behavior when the
option is set.
In [1], we used 'zip(1)' to create *.zip files in these integration
tests because ZIP files begin with the header:
[]byte{0x50, 0x4B, 0x03, 0x04}
And thus are detected as 'application/zip' by http.DetectContentType().
However, this 'zip(1)' program does not exist on Windows, hence the
recent test failures (starting as early as [1]).
Instead, let's use 'tar -czf', which creates gzip-compressed tarballs,
and begin with the header:
[]byte{0x1F, 0x8B, 0x80}
Thus are detected as 'application/x-gzip' by http.DetectContentType().
This should allow this test to run on AppVeyor (and more generally, on
Windows as a whole) again.
[1]: 938df5c4 (tq/basic_upload.go: disable Content-Type detection by
configuration, 2018-07-31)
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)
