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.
