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'
Currently, if a user runs git lfs ls-files with lfs.fetchexclude set to
*, then all files are excluded from the output. This doesn't make much
sense, since the lfs.fetchinclude and lfs.fetchexclude options are
documented to work only on fetches. Let's ensure that we don't load the
fetch filters by default when performing a non-fetch operation so that
git lfs ls-files isn't affected by these exclusions.
The printf(1) command, like it's C cousin, takes a format string as its
first argument. If a shell variable is passed as the first argument, it
will be interpreted as a format string; this can lead to surprising
behavior and can cause the test suite to fail if we accidentally insert
a format string character into the variable.
Modify all the places in the individual tests that we use a plain quoted
variable as the format string by running the following Ruby one-liner:
ruby -i -pe '$_.gsub!(/printf "\$/, %q(printf "%s" "$))' t/t-*.sh
Avoid modifying the test helpers, as there are places (such as calc_oid)
where we want to pass text containing escapes (such as "\n") and have
those be properly interpreted by printf(1).
Since e2717688 (commands: scan repository index in git-lfs-ls-files(1),
2017-12-19), we have traversed the contents of the index when showing
files in 'git lfs ls-files'.
The purpose of this was to match behavior in 'git ls-files', where the
index is also shown by default.
However, when given an argument, 'git lfs ls-files' will traverse
starting from a specific revision, so showing the index unconditionally
causes a problem here. It does not make sense to show the current state
of the index when listing files when given a starting point explicitly.
So, let's skip calling into the gitscanner code when given an explicit
reference to start from (even if that reference is HEAD, since this
likely indicates that the user does not want to scan the index, too).
In 05d65e75 (commands/ls-files: do not accept '--all' after '--',
2018-03-20), we encountered an interesting situation in which the
following command invocation:
$ git lfs ls-files -- --all
Was treated as if "--all" were a reference name, and thusly passed to
git.ResolveRef(), and ultimately to "git rev-parse", as "git rev-parse
--all", which is a valid execution of "git rev-parse".
Thus, we'll get an odd result. Instead, let's trap that case early, and
return an appropriate error.
