We add a number of tests of the functionality of the new
--pointers option to the "migrate info" command in order
to confirm it works as expected in all modes, and both with
and without Git LFS pointers in the test repositories.
We also add tests of repositories where some file extensions
are tracked in .gitattributes files and the corresponding blobs
should be Git LFS pointers, but are not yet. In these cases,
we do want to report these file extensions in summary data of
the output listing.
In order to ensure our tests succeed on Windows, we alter
several fixture setup functions to create the .gitattributes
files using "echo" instead of "git lfs track". This keeps
the line endings consistent across platforms, and therefore
the .gitattributes file sizes in the "migrate info" summaries.
Currently, if we have a file and it contains an extension, we'll add
that extension to the list of paths that should be placed in
.gitattributes. However, if the file does not contain an extension, it
won't be listed at all. As a result, we may convert a file flagged by
the --above option but never cause Git to filter it properly.
Let's fix this by writing an attribute into the repository with the path
relative to the root if we don't contain an extension. This means that
people can store typical Unix binaries, which lack extensions, as LFS
files more easily.
The purpose is to allow users to tell git-lfs to migrate
all files over a particular threshold without having to determine
the various paths and patterns that would. This is very useful
for large code bases with inconsistent history of adding large
files in different places. This option makes it possible to
supply `git-lfs migrate import --everything --above=1Mb` and
have git-lfs do the convenient thing and rewrite history.
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'
In future versions of Git, the default branch name will likely change
from "master" to "main". We'd like to make this change as well. In
order to make the default branch the same in all versions of Git, let's
use a template directory to initialize the repositories that we're
creating. This works with Git 1.8.3.1, which is available in CentOS 7,
as well as all newer versions.
For now, we set the branch name to "master", but in a future commit,
we'll change the name to "main".
We move the native_path helper into testenv.sh so that we can
canonicalize the GIT_TEMPLATE_PATH environment variable. Git itself
canonicalizes this internally and the tests for git lfs env will fail if
we don't canonicalize it ourselves.
