When an attribute does not start with '!', '-', or contain an '=', we
had previously treated it as malformed. Instead, assume that it is a
'set' attribute, which we interpret to mean as being set implicitly to
"true" (and therefore the dual of the '-' prefix).
From the relevant documentation [1]:
Set
The path has the attribute with special value "true"; this is
specified by listing only the name of the attribute in the attribute
list.
[1]: https://git-scm.com/docs/gitattributes
When writing this test in 58ae7f7f (git/gitattr: introduce package
'gitattr', 2018-07-06), code was introduced to check each line of a
multi-line .gitattributes file.
Since each line was similar, there's a good chance that we did some
over-eager copy/pasting, and wound up checking the same thing twice.
To fix this, let's increment the index of the line that we're testing,
to ensure that all lines are tested correctly.
This commit introduces package github.com/git-lfs/git-lfs/git/gitattr,
which manifests a tree-like representation of a repository's
.gitattribute file(s).
It introduces the following top-level and member functions:
- func ParseLines(r io.Reader) ([]*Line, error)
Parses the lines of a .gitattributes-like io.Reader into a set of
wildmatch to attribute-set pairings, or an error if one was
encountered.
- func New(db *gitobj.ObjectDatabase, t *gitobj.Tree) (*Tree, error)
Visits all trees reachable from "t" in a depth-first search to
reconstruct a tree-representation of all .gitattributes file(s) in the
repository.
- func (t *Tree) Applied(to string) []*Attr
Finds all attributes in-order that are applied to "to" relative to the
receiving *Tree's location in the repository's tree structure.
This will become useful in subsequent commits when this is used to scan
a repository's .gitattributes files before rewriting the blobs in that
repository during the forthcoming 'git lfs migrate import --fixup' mode.
