> If you add this to your .gitattributes:
Not applicable to GitHub etc though.
I'm also not seeing any speed differences when using -y/yarn lockfile. Why not make it the default?
Not applicable to GitHub etc though.
I'm also not seeing any speed differences when using -y/yarn lockfile. Why not make it the default?
GitHub (disclosure: where I work) does respect some directives in a repo’s .gitattributes file. For example, you can use them to override language detection or mark files as generated or vendored to change diff presentation. You can also improve the diff hunk headers we generate by default by specifying e.g. `*.rb diff=ruby` (although come to think of it I don’t know why that’s necessary since we already know the filetype — I’ll look into it)
In principal there’s no reason we couldn’t extend our existing rich diff support used for diffing things like images to enhance the presentation of lockfile diffs. There’s not a huge benefit for text-based lock files but for binary ones (if such a scheme were to take off) it would be a lot more useful.
Here's a test demonstrating that this usage works: https://github.com/github/linguist/blob/32ec19c013a7f81ffaee...
Quoting the docs on finding files:
https://docs.github.com/en/search-github/searching-on-github...
> File finder results exclude some directories like build, log, tmp, and vendor. To search for files within these directories, use the filename code search qualifier.
(The inability of quick jumping to files from /build/ folder with `T` has been driving me crazy for YEARS!)
Correct me if I'm wrong, but checking those two files:
- https://github.com/github/linguist/blob/master/lib/linguist/...
- https://github.com/github/linguist/blob/master/lib/linguist/...
I don't see `/build` matching anything there. So to me this `/build` suppression from search results seems like controlled by some other piece of software at GitHub :/
Also, files from `/build` are not hidden in diffs, so per this table: https://github.com/github/linguist/blob/HEAD/docs/overrides.... they are not "linguist-generated".
I think it's reasonable to respect the linguist overrides here so I'll open a PR to remove entries from the exclude if the repo has a `-linguist-generated` or `-linguist-vendored` gitattribute for that directory [1]. So in your case you can add
build/** -linguist-generated
Thanks for pointing this out! Feel free to DM me on twitter (@cbrasic) if you have more questions.
[1] Recursively matching a directory with gitattributes requires the `/**` syntax unlike .gitignore: https://git-scm.com/docs/gitattributes#:~:text=with%20a%20fe...