Currently we process pointers in a rather lax way and accept a variety
of non-canonical pointers, such as those with CRLF line endings or a
size value of 0 (which should be an empty file instead). However, we
have a flag to indicate whether the pointer is canonical when parsing
it, so let's add a --strict flag so that we can allow people to reject
non-canonical pointers.
Note that while strictness is not the default, we add a --no-strict flag
as well so we can allow people to use it now and change the default at a
later time (probably 4.0).
Using a simple exclamation point in front of a command inverts the sense
of the command, but it also disables the error checking of "set -e". As
a result, let's use "&& exit 1 || true" since that will cause error
checking to be enabled.
We have used the 'git-lfs-pointer(1)' command historically to compare
varying implementation of the Git LFS protocol. This has been done by
passing both `--file` and `--stdin` to the command, which will in turn
compare the contents of both handles and return appropriately whether
they are the same or different.
One use case that Git LFS pointer does not yet support directly is
_checking_ to see whether a given file is a valid Git LFS pointer. This
is a different use-case than before, since we aren't doing any
comparison, we're simply checking whether the official implementation of
Git LFS can parse a given stream as a pointer.
As an aside, one way to do this today is the following:
$ git lfs clean < a.txt | git lfs pointer --stdin --file my.ptr
Where we first generate a pointer of the file 'a.txt' (via
`git-lfs-clean(1)`), and then redirect that to `git-lfs-pointer(1)`
against our own file.
Let's make this above incantation easier to execute by providing a
functionally equivalent `--check` option. Running `git lfs pointer
--check` (and passing either `--file`, or `--stdin`) will return either
1 or 0 depending on whether or not the given pointer file was invalid or
not.
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).
