First of all great collection! 👏

Secondly, I'm wondering if it's on purpose that you don't include a gitconfig with the diff drivers. For example the elixir gitattributes: diff=elixir is redundant if there's no [diff elixir] section in my gitconfig with a textconv command. It's true that sometimes you can do many things, different things to convert a binary to text, but maybe this repo can also be a collection of those alternate diff drivers (?!).

EDIT: my example is not perfect (elixir is builtin since 2y?!). So to rephrase: would you consider including custom diff drivers for binary files, or is the intention for this collection to stick to builtin drivers?

https://github.com/gitattributes/gitattributes

👆 is that the "official" most-community-supported .gitattributes template repo, or is it this one? If it's not that one, it looks like it's a fork of this repo. Would it be a good idea to reach out to @jozefizso to see if they'd be interested in hosting this repo there? I notice that there was previously some anti-organization sentiment in #171 so idk. regardless of whos ego should get the credit for this .gitattribbutes repo, I definitely think that the @gitattributes organization is a killer name for a project like this and it's really odd that this repo isn't already hosted there. Unless https://github.com/gitattributes/gitattributes is the "official" repo? 😵

taken from this example from @szepeviktor's small-project and added a couple more common config files to ignore

open to improvements/suggestions and will create a PR after some time for feedback

/.gitignore export-ignore
/.gitattributes export-ignore
/.editorconfig export-ignore
/.circleci export-ignore
/.travis.yml export-ignore
/.github/ export-ignore
/phpcs.xml export-ignore
/phpunit.xml export-ignore
/phpstan.neon export-ignore
/psalm.xml export-ignore
/tests/ export-ignore

The Generator combines the complete content of the individual *.gitattribute files. So, there is then duplication of content in the result.

Is this an issue?

i.e. "* text=auto" ordinarily will be overridden by subsequent rules top to bottom.

What happens if there are then multiple lines of "* text=auto" throughout the file? Does this cause some form of reset of the overrides? Can this generated file actually be used, or do we first need to filter this combined file and remove all duplication?

Would be great to start adding file types that should be stored using Git LFS. Obviously I could start submitting PRs but this is for visibility.

Since adding a .gitattributes file to my team's repo January 11th this year, I've found myself toggling the -diff option a bit too frequently. Thus, I am changing our .gitattributes file to NOT use the -diff (binary) option.

All devs can still individually treat lockfiles as binary,
toggling this setting on/off as they please, like so:

1. Add this to your ~/.gitconfig file:

[core]
  attributesfile = ~/.gitattributes_global

2. Add this to a new ~/.gitattributes_global file:

# Better off adding .gitattributes to individual repos.
*.lock            text eol=lf -diff
package-lock.json text eol=lf -diff
pnpm-lock.yaml    text eol=lf -diff
yarn.lock         text eol=lf -diff

On Windows, with core.autocrlf = true, shader graphs are automatically tagged as modified when you open them because ShaderGraph internally uses LF line endings in its serialization code.

This behavior is quite annoying and I believe could be improved by forcing LF for shader graph files.

These lines in Unity.gitattributes should be modified to change this behavior:

*.shadergraph           text linguist-language=json
*.shadersubgraph        text linguist-language=json

Happy to provide a pull request if that helps!

Hi everyone.

It's my first pull request and I'd like to know what you all think of the idea of a .gitattributes for .md files.

The reason for this request would be to identify .md files, there are technical documentation files in software, as well as repositories of tutorials or articles that are written or formatted in .md, so there would be a need in some cases to count in the analysis(github-linguist)... .md files.

I would be happy if this pull request is accepted.

This might be a stupid question from an beginner, but what is needed apart from installing Git LFS and running git lfs install, to be able to used the .gitattributes files from this repository?

Commiting the .gitattributes files of this repository doesn't work for binary patterns. The files I supspect to be tracked by LFS are still committed to the repository and not stored on the Git LFS server.

Only if a filter (*.jpg filter=lfs binary) is added in the .gitattributes it works. On StackOverflow I was told that the filter is mandatory, but why is it not part of any of the tempaltes from this repository?

Projects vary greatly in nature. So, providing templates of .gitattributes is not an effective solution. I have created a .gitattributes generator. Currently its not even in beta... You are welcome to contribute to it.
http://ihopepeace.github.io/gitattributes_generator/

What about add .go (Golang) files?

We need a gitattributes file for tex files (LaTeX documents)

Searching inside this repo for pdf reveals the following:

# /Common.gitattributes
*.pdf      diff=astextplain
*.PDF      diff=astextplain

# /Fountain.gitattributes
*.pdf      binary

# /Delphi.gitattributes
*.pdf  text

# /Unity.gitattributes
*.pdf               binary

# /Web.gitattributes
*.pdf             binary

I would be happy to create a PR that normalizes all the attributes like so:

*.pdf binary diff=astextplain

but I am not sure if there is a reason for the Delphi attribute to be text.

Can someone more knowledgeable confirm if my proposed change is ok?

Some file types should have eol=lf specified in addition to text. The thing that comes to mind are shell scripts (*.sh and maybe things like *.bash if we're being exhaustive). This matters for users on Windows who use Cygwin because the default eol is CRLF and by default Cygwin fails when it hits a CR. I realize this affects a narrow subset of users and this suggestion is a little opinionated but I believe it's a good change to make.

See line 35 in Web.gitattributes for an example where this could be used.

Also, it may make sense for Windows scripts (*.bat, *.cmd, and *.ps1) to use eol=crlf since these are for use specifically in an environment which uses CRLF by default, but I personally have never seen any failures due to LF usage here (other than Notepad not treating LF as a proper linebreak, but I view that as a problem with Notepad). This is just another example of where is could make sense but I don't think it's necessarily a good idea. Batch scripts cannot properly jump to labels when line endings are not CRLF.

There should be WordPress template also as there are certain plugins that generates larger files that can be used to keep in some conditions,

few plugins I know i.e. All in One Migration that generates a backup file in wp-content/ai1wm-backups with extension of *.wpress
also updrafts if configured to store local, keeps files in wp-content/updrafts

sharing my personal experience, sometimes I also keep the DB file in the repo i.e. wordpress.sql file in the repo incase I need that later..

Hi.

I would like to know if I've thought about creating a folder called ".override" to add .gitattributes files related to document files like txt, html, markdown, xml etc.

Example, concept: .override/Markdown.gitattributes

Have you all ever thought of creating a folder called ".override" to add .gitattributes files related to document files like txt, html, xml, markdown?

Hi all.

I wonder if you've all thought about creating a GitHub organization for gitattributes. Have you all thought about creating a GitHub organization for gitattributes?

One advantage is that you can create many packages with the same organization name.

example

• "https://github.com/gitattributes/markdown.gitattributes"
• "https://github.com/gitattributes/c.gitattributes"
• "https://github.com/gitattributes/cpp.gitattributes"

or

• "https://github.com/common-gitattributes/markdown.gitattributes"
• "https://github.com/common-gitattributes/c.gitattributes"
• "https://github.com/common-gitattributes/cpp.gitattributes"

these links are conceptual.

Hello @alexkaratarakis ! 👋

I notice that there's a lot of open issues on this repo. Are you still actively maintaining this project? Are you looking for someone to help out? Is this project shoved-to-the-side-ish? Are improvements and additions encouraged? Discouraged?

In particular I notice that there's this open PR that was open so long the original poster since deleted their account 🤯 #177

@spenserblack appears to have had a similar idea to yours to make a centralized hub for .gitattributes templates/presets https://github.com/spenserblack/.gitattributes, so it might be cool to add them as a Collaborator? I'm not sure on the etiquette of asking someone else to combine projects 😅

I can also help closing/fixing/doing issues. ❤️

According to this blog, merge=union causes silent troubles.

Hi

Add new filetypes to gitattributes for visual studio

*.vcxproj text eol=crlf
*.vcxitems text eol=crlf
*.props text eol=crlf
*.filters text eol=crlf

In the file VisualStudio.gitattributes, all file-types are listed twice, with two setups to choose from.
However, there is one mismatch:
*.wmaproj text eol=crlf
vs
#*.wwaproj merge=binary
After some searching, it seems that the correct spelling is .wwaproj, which is recognized as a "WWA Project File" that can be opened with Visual Studio:
https://www.pcmatic.com/company/libraries/fileextension/detail.asp?ext=wwaproj.html
While the extension .wmaproj does not seem to be recognized.

Line 4 of Common.gitattributes:

# https://www.davidlaing.com/2012/09/19/customise-your-gitattributes-to-become-a-git-ninja/

This link is broken.

The gitattributes(5) link at the bottom of the main README is broken. The line is quoted below. To resolve this issue, I recommend updating the link.

For more information on gitattributes: gitattributes(5) and for Github-specific grammar: Linguist docs

Not advocating for mjs, just completeness

Usually many projects involving R are made using a .rmd file for scripting, instead of the usual .R, but this file isn't recognized by linguist so with *.Rmd linguist-language=R in the .gitattribute you can get more accurate statistics about the use of R in the project

Bottom line: Why is it there? Isn't *.thing text the normal default? 🤔

https://www.git-scm.com/docs/gitattributes

It would appear from my limited understanding that leaving it unset for these *.json and other text-like files is best so that it respects the user's preference of core.autocrlf, right? Sorta like how most .gitignore templates do not include .DS_Store in them and expect a global ~/.gitignore to take care of that.

examples of this where I think it should be reconsidered:

https://github.com/alexkaratarakis/gitattributes/blob/2dfb1d9df6e22790881048871019ac8cf7a76011/Perl.gitattributes#L5-L6

https://github.com/alexkaratarakis/gitattributes/blob/2dfb1d9df6e22790881048871019ac8cf7a76011/Fortran.gitattributes#L6-L10

https://github.com/alexkaratarakis/gitattributes/blob/2dfb1d9df6e22790881048871019ac8cf7a76011/Ballerina.gitattributes#L9-L24

(those were all just found randomly clicking on the sidebar lmao)

idk

I initially stumbled upon this when seeing *.ps1 has eol=crlf. Merged PR #125 assumes that PowerShell is cross-platform and therefore shouldn't have CRLF specified, while the merged PR #129 overrides the previous one and assumes it is Windows-specific. I think that *.ps1 files shouldn't have CRLF specified by default, since teams can use PowerShell as their terminal on both Windows and Unix-like systems.

The general question of whether line endings should be coerced at all in .gitattributes is worth asking. This guide suggests that .gitattributes overrides the core.autocrlf setting, which could be surprising for the uninitiated. I personally prefer using core.autocrlf to standardize across platforms, and line ending overrides in .gitattributes are surprising to me, at least.

I'm curious as to your rationale for specifying line endings in .gitattributes. I think it's fine whatever you decide! But maybe a disclaimer is warranted in the readme, as to the philosophy behind this decision. If it's signposted, then users with a different mindset can remove those EOL specifications. I know it's hard to devise a single "source of truth" for anything, let alone the esoteric details behind .gitattributes, so to attempt to standardize on anything at all is an admirable effort.

I've seen some disturbing things about svg files. They were first defined as text in Graphics.gitattributes (0c2e704), which has been merged in Common.gitattributes (99042dc), then changed to binary (6e33907). Furthermore, svg has been deleted from Java.gitattributes (good thing), with a comment saying it should be binary (199fb63).

Afaik, svg is a text (XML) file (unlike other graphics files). Is there a reason for considering them as binary ?

Terraform and hasiCorp use their own format.

.tf for terraform config files
.tfvars for variables.
.hcl -> hasicorp config lang (general catch all for many of their products)

I went with:

*.tf text eol=lf
*.tfvars text eol=lf

https://github.com/github/gitignore/blob/main/Jekyll.gitignore
https://github.com/github/gitignore/blob/main/Node.gitignore

It seems like, if anything, web.gitattributes should be node.gitattributes. 🤷‍♂️ since all that tooling is Node.js-related even if it's final destination is a web browser.

using this with extensions is good, but not good enough. "gitattributes.io" has a good api that can be used from cmd (with a code similar to gitignore.io gi command at https://docs.gitignore.io/install/command-line ). However, is "gitattributes.io" is updated? Or are there a way to use one of your tools with a url that has some parameters with it?
A command line tool or connection somethingg... is necessary.

Will it work if we describe all rc files with .*rc text?
The same with .*ignore

git check-ignore says .*rc matches .eslintrc

 git check-ignore -v -- .eslintrc
.gitignore:36:.*rc      .eslintrc

many templates, e.g., common and web contains default wildcard text config, this will override the previous text set status.

jar/so/dll files: the 'binary' macro is missing !

.tina/__generated__/ is linguist-generated
https://tina.io/

In the readme, it's stated that:

Similarly to the .gitignore Templates, we're trying to build templates for .gitattributes.

I think that the https://github.com/github/gitignore repo does a decent job of segmenting the official language-level stuff as top-level official stuff and then having Global configurations that are more for supporting global tooling (like your custom IDE) that's intended to go in your global ~/.gitignore file. They also have more niche templates in the community folder which is cool!

I think that adopting something like that in this repository would be a good idea? Maybe?

Hi,
The repo does currently not have a license file. I'd suggest MIT. I can add a pull request with that if you'd like?
PS: May also require an additional line in the .gitattributes file.
PPS: See https://help.github.com/articles/open-source-licensing/

Hi,
Is there a reason the diff attribute hasn't been set for any language source files (besides C#)?

Thanks!

Consider clarifying in the README.md if you can have more than 1 .gitattributes file, and, if so, the "best practice" for naming / location?

This is my first time really looking into .gitattributes, and I see Common.gitattributes and Python.gitattributes in this repo that would be relevant to my project. However, it's not clear if I can just copy/paste those files, with those names, into my project, or if I'm supposed to combine them into a single .gitattributes, etc.

Even if it's in a separate GitHub repository, I think a gh CLI extension is a good idea. It'd be cool to have a CLI tool in addition to the web tool that's listed in the readme. It'd be even cooler if it were "official" as in same owner (alexharatarakis or organization; though I see an organization got shot down pretty hard in #171 ) or even same repo (monorepo or something)

I know @spenserblack had this idea for their gitattributes collection spenserblack/.gitattributes#2 and I think that same idea is good one for this collection too.

I've got the beginnings of one here https://github.com/jcbhmr/gh-gitattributes (it uses Bash lmao not even Go like https://github.com/garnertb/gh-gitignore)

Just thought I'd bring this up.