Following on from the changes in PR #4781, we can make
additional message strings translatable using the
tr.Tr.Get() method.
Because this method performs printf(3)-style format string
parsing and interpolation, we can simplify some of the
surrounding calls, e.g., from fmt.Errorf() to errors.New(),
and from fmt.Fprintf() to fmt.Fprintln(). This ensures
that if either the translated text or any interpolated
arguments happen to contain character sequences that would
be interpreted as Go format specifiers (e.g., "%s" or "%d"),
these will not result in warnings such as "%!s(MISSING)"
in the output text.
Note also that we try to remove newlines from the message
strings were possible and change the surrounding calls to
append them instead, e.g., with fmt.Fprintln().
There are two types of pattern matching with wildmatch patterns in Git:
gitignore and gitattributes patterns. We'd like to support both, but
without the lazy matching that was the cause of so many problems before.
Add a type of pattern to use when creating a new filepathfilter and use
it to instantiate the wildmatch pattern with the proper flags. Remove
the dirs flag, which is unused and has been for sometime, and also the
stripping of trailing slashes, which we want to use to indicate a
directory. Drop the non-strict mode since our pattern matching is now
much improved and compatible with Git.
For backwards compatibility reasons, we transform some wildmatch
patterns. However, when we're reading a pattern from .gitattributes, we
do this as well, and these transformations can cause us to fail to match
some things that Git does match.
While we want to retain the behavior of the command-line options for
compatibility, at least until 3.0, there's no reason for us to mismatch
patterns in .gitattributes: that's clearly a bug. Let's add an option
to our pattern constructor to match patterns strictly so we can enable
it when reading from .gitattributes, and disable our pattern
manipulation when it's enabled.
To help us improve debugging, let's also add the value of the strictness
flag when printing the transformed pattern.
Whenever we use a file path filter and there are no included patterns,
we default to assuming the files match. For many cases, this is fine,
but this is not useful for checking whether a file is lockable: if no
files are listed as lockable, then no files are lockable.
Let's add an option for our filters to specify the default value if no
patterns match. If that default is false, like it should be for
locking, then skip traversing the exclude patterns altogether, since
anything that's not included cannot change the result. We test both the
case that lockable patterns are present and absent in our test.
The file path filter can mark a file as either accepted or rejected.
However, one of the messages that says that a file was rejected is in
the main code path, and is therefore always executed, even if the file
is actually accepted. This leads to contradictory messages and noisier
output.
Ensure that we indicate that a file is rejected by the filter only if it
is indeed rejected; otherwise, say only that it is accepted.
