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'
When we add a pattern with git lfs track, we inform the user if the
pattern is already supported. However, we fail to do so when the
--filename argument is passed, due to not having encoded the pattern at
that point.
To solve this problem, hoist the code that encodes the filename as a
pattern so it happens before we check if we already have such a pattern.
When using "git lfs track --filename" with a filename with spaces, the
brackets surrounding the character class for representing spaces were
also escaped, leading to the space not being interpreted correctly.
Update the escaping function we use to handle all of our escaping needs,
performing the escaping in the correct order so that we can handle
spaces correctly.
Normally, the arguments to "git lfs track" are taken as glob patterns.
This is generally useful, but sometimes there are filenames that contain
special characters. Add a "--filename" option that forces arguments to
be taken as literal paths instead of glob patterns to make handling
these files easier.
In the test helpers, pass -F to grep so that our unusual file names
don't trigger undesired pattern matching. This has no effect on other
tests, as they all pass a literal filename here.
We currently use core.autocrlf to guess what line endings a user might
want to have for the .gitattributes file if it lacks line endings
already. When the user has specified core.autocrlf=input, they have
specified that they don't want line endings to be changed. This isn't
explicitly an indication that they want to use CRLF line endings,
especially if they are on a non-Windows system.
Therefore, if we need to guess what line endings to use with
core.autocrlf=input, guess the system line endings, not CRLF.
Git specifically defines the "-filter" syntax as meaning "filter=false".
Consequently, it's not valid to write "-filter=lfs", since that provides
two possible values for the filter attribute. Since this is not valid
syntax, adjust the line in the tests.
We're listing excluded patterns by default to help people identify
patterns deeper in the tree that may conflict with patterns in shallower
parts of the tree. However, it's possible that people have been parsing
the output of git lfs track, even though it's a porcelain command, not a
plumbing command. To help these people keep their programs working, add
support for a --no-excluded flag that omits listing excluded paths.
Note that the previous behavior of listing paths that were excluded from
Git LFS as tracked paths is not supported, because it was both incorrect
and confusing.
Currently, if a user has disabled Git LFS for a pattern in a
.gitattributes file (such as in a subdirectory) by writing
"-filter=lfs", we render the pattern as a tracked pattern in "git lfs
track", even though those paths are not enabled for Git LFS.
Improve this situation by listing excluded patterns as well as tracked
patterns. Compute whether a pattern is excluded by looking for an
attribute entry that starts with "-filter" and if so, list the entry as
excluded. Add tests for both the "-filter" and "-filter=lfs"
situations.
