alexkaratarakis / gitattributes Goto Github PK
View Code? Open in Web Editor NEWA collection of useful .gitattributes templates
License: MIT License
A collection of useful .gitattributes templates
License: MIT License
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.
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?
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?
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..
We need a gitattributes file for tex
files (LaTeX documents)
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 Batch scripts cannot properly jump to labels when line endings are not 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.CRLF
.
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.
or
these links are conceptual.
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 ?
Hi,
Is there a reason the diff
attribute hasn't been set for any language source files (besides C#)?
Thanks!
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?
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? ๐ต
According to this blog, merge=union
causes silent troubles.
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/
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!
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:
(those were all just found randomly clicking on the sidebar lmao)
idk
jar/so/dll files: the 'binary' macro is missing !
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.
many templates, e.g., common and web contains default wildcard text config, this will override the previous text set
status.
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.
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.
Not advocating for mjs, just completeness
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?
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
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.
I have tried researching this and have hit a bit of a wall and was hoping the maintainers here could clear it up or point me in the right direction.
I have not seen diff=astextplain
before, so I did some digging and found the following:
SRC: https://stackoverflow.com/questions/28146244/what-is-the-difference-between-diff-and-diff-astextplain
diff=astextplain
(msysGit only): converts those files (under the condition that their extension be*.doc
,*.rtf
, etc.) to a text format before generating their diff....
The accepted answer is outdated. msysGit has been superseded by Git for Windows 2.x.
astextplain
is a script available in Git for Windows'git-extra
package and can be read online.
So it is Windows specific, and only when a specific helper is installed. This already confuses me because now Linux users, MacOS users, and Windows users who don't install the helper will have a different experience from those that are on Windows and do have the helper installed. Since I haven't worked with diff=astextplain
before, I don't know if this is a risk or optional convenience/enhancement.
I don't have experience with shell scripts, but this one seems easy enough to tell that it is checking for specific, case-sensitive file extensions. If it isn't found, the process exits with an error.
case "$1" in
*.ods | *.ODS | *.odf |*.ODF | *.odt | *.ODT)
odt2txt "$1" || cat "$1"
;;
*.doc | *.DOC | *.dot | *.DOT)
case "$(file --brief --mime-type "$1")" in
application/msword)
out=$(antiword -m UTF-8 "$1") && sed "s/\^M$//" <<<$out || cat "$1"
;;
*)
cat "$1"
;;
esac
;;
*.docx | *.DOCX | *.dotx | *.DOTX | *.docm | *.DOCM | *.dotm | *.DOTM)
docx2txt.pl "$1" - || cat "$1"
;;
*.pdf | *.PDF)
out=$(pdftotext -q -layout -enc UTF-8 "$1" -) && sed "s/(\^M$)|(^\^L)//" <<<$out || cat "$1"
;;
# TODO add rtf support
*.rtf | *.RTF)
cat "$1"
;;
*)
echo "E: unsupported filetype $1" 1>&2
exit 1
;;
I looked at the commit history for asplaintext
and found no mention of *.epub
or *.EPUB
, so if a file is diffed with that shell script, won't it always exit with an error?
When I look at the commit history for the *.epub diff=astextplain
line in this repo, it leads me to #166
This pull request started as Git LFS and then evolved into astextplain
, but nothing really explained what it was doing or how it works.
With the above in mind, I am left confused and asking the question that is the title of this issue: What does diff=astextplain
for *.epub
accomplish? and how does it accomplish it?
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?
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
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.
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
Line 4 of Common.gitattributes
:
# https://www.davidlaing.com/2012/09/19/customise-your-gitattributes-to-become-a-git-ninja/
This link is broken.
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
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:
~/.gitconfig
file:[core]
attributesfile = ~/.gitattributes_global
~/.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
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
.tina/__generated__/
is linguist-generated
https://tina.io/
What about add .go
(Golang) files?
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/
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.
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
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. โค๏ธ
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.