search

RehanSaeed / rehansaeed.github.io

Muhammad Rehan Saeed's Blog
https://rehansaeed.com
30 stars 6 forks source link

[Comment] .gitattributes Best Practices #80

Open RehanSaeed opened 4 years ago

RehanSaeed commented 4 years ago

https://rehansaeed.com/gitattributes-best-practices/

RehanSaeed commented 4 years ago

Hussein Abdl Ghani Hussein Abdl Ghani commented on 2019-07-23 01:54:24

Great post Muhammad, I enjoyed every bit of it and became more intrigued about .gitattributes and what else it offers. I would love to see you on Medium or dev.to. Keep the good work!

RehanSaeed commented 4 years ago

Muhammad Rehan Saeed Muhammad Rehan Saeed commented on 2019-07-23 09:11:08

Great post Muhammad, I enjoyed every bit of it and became more intrigued about .gitattributes and what else it offers. I would love to see you on Medium or dev.to. Keep the good work!

I'm not a fan of third party blogging services. I like to own my own words. Thanks for reading!

RehanSaeed commented 4 years ago

Some dude on the internet Some dude on the internet commented on 2019-07-23 12:13:59

Most of the programming editors these days support working with either line ending, regardless of the platform they run on, and most other tools (compilers etc..) are line-ending-agnostic.

I've found I've had more problems caused by git trying to be helpful and converting my line endings for me, than the other way around. So I'd say best practice is to use * -text in the .gitattributes and add .editorconfig that enforces the projects preferred line endings. An added benefit is that you can also specify file encodings in your .editorconfig file.

RehanSaeed commented 4 years ago

Muhammad Rehan Saeed Muhammad Rehan Saeed commented on 2019-07-23 17:00:34

Most of the programming editors these days support working with either line ending, regardless of the platform they run on, and most other tools (compilers etc..) are line-ending-agnostic.

I've found I've had more problems caused by git trying to be helpful and converting my line endings for me, than the other way around. So I'd say best practice is to use * -text in the .gitattributes and add .editorconfig that enforces the projects preferred line endings. An added benefit is that you can also specify file encodings in your .editorconfig file.

That's a really great point about the .editorconfig file having some overlap. Unfortunately, not all editors (I use Nodepad2 for quick edits sometimes) support it.

It's a shame I don't know who you are but thanks stranger!

RehanSaeed commented 4 years ago

Filip Å  Filip Å  commented on 2019-07-24 14:28:05

Hey! Great article. I was planning to reorganize my project's Git files so it was useful for me. There are still a few things and questions I would like to mention here.

Git supports defining language-aware diffs in .gitattributes (like *.html diff=html and *.py diff=python). Is it needed or to manually specify that or will Git automatically detect language and use correct diff for it?

There is also something that is often useful. This is export-ignore which allows you to exclude files from archive. This is useful if you want to exclude tests or other unneeded files from the generated archive.

RehanSaeed commented 4 years ago

Muhammad Rehan Saeed Muhammad Rehan Saeed commented on 2019-07-25 09:16:08

Hey! Great article. I was planning to reorganize my project's Git files so it was useful for me. There are still a few things and questions I would like to mention here.

Git supports defining language-aware diffs in .gitattributes (like *.html diff=html and *.py diff=python). Is it needed or to manually specify that or will Git automatically detect language and use correct diff for it?

There is also something that is often useful. This is export-ignore which allows you to exclude files from archive. This is useful if you want to exclude tests or other unneeded files from the generated archive.

These are good questions that I haven't explored. To be honest, I don't use the git diff tool, I prefer to use Visual Studio/VS Code or I'm currently trying out Semantic Merge (semanticmerge.com) which is interesting.

RehanSaeed commented 4 years ago

your bro your bro commented on 2019-11-26 05:44:13

################################################################################

This .gitignore file was automatically created by Microsoft(R) Visual Studio.

################################################################################

/Source/abc/abc/abc/bin
/Source/abc/abc/.vs/abc/v15

My file look like this what i can do

RehanSaeed commented 4 years ago

Muhammad Rehan Saeed Muhammad Rehan Saeed commented on 2019-11-29 17:45:07

################################################################################

This .gitignore file was automatically created by Microsoft(R) Visual Studio.

################################################################################

/Source/abc/abc/abc/bin
/Source/abc/abc/.vs/abc/v15

my file look like this what i can do

What do you want to do?

RehanSaeed commented 4 years ago

Sandburg Sandburg commented on 2020-05-01 13:51:40

Git has already many rules for binary files. It can already detect it. So, beginning by a normalization * text=auto ... I'm not sure it's the better idea. The worth would be to * text, ah ah ah. On the other hand, setting *.sh text eol=lf and *.bat text eol=crlf is mandatory. Because sadly, git can't do that. Or alloweds himself not to do so... Nowadays, we work so much multi plateform, docker and so on. You clone from one point, you work from another... the line endings on many formats have to be hardcoded, not free.

RehanSaeed commented 4 years ago

Muhammad Rehan Saeed Muhammad Rehan Saeed commented on 2020-05-07 12:51:40

Git has already many rules for binary files. It can already detect it. So, beginning by a normalization * text=auto ... I'm not sure it's the better idea. The worth would be to * text, ah ah ah. On the other hand, setting *.sh text eol=lf and *.bat text eol=crlf is mandatory. Because sadly, git can't do that. Or alloweds himself not to do so... Nowadays, we work so much multi plateform, docker and so on. You clone from one point, you work from another... the line endings on many formats have to be hardcoded, not free.

There are some heuristics that detect the file type. I spent a lot of time trying to understand how good they are and came to the conclusion that it's better to be explicit.

TysonMN commented 4 years ago 
# Documents
*.pdf filter=lfs diff=lfs merge=lfs -text

# Images
*.gif filter=lfs diff=lfs merge=lfs -text
*.ico filter=lfs diff=lfs merge=lfs -text
*.jpg filter=lfs diff=lfs merge=lfs -text
*.pdf filter=lfs diff=lfs merge=lfs -text

What is the point of having PDF in there twice?

RehanSaeed commented 4 years ago 
# Documents
*.pdf filter=lfs diff=lfs merge=lfs -text

# Images
*.gif filter=lfs diff=lfs merge=lfs -text
*.ico filter=lfs diff=lfs merge=lfs -text
*.jpg filter=lfs diff=lfs merge=lfs -text
*.pdf filter=lfs diff=lfs merge=lfs -text

What is the point of having PDF in there twice?

Thanks, fixed.

TysonMN commented 4 years ago

Many of your repositories have the same duplication.

RehanSaeed commented 4 years ago

Many of your repositories have the same duplication.

Oh my god! Thanks for letting me know.

urbasus commented 2 years ago

Feeling like the biggest party pooper saying this, but my experiences of using eol= are all bad. Makes for weird cases where your local copy differs from the remote, but not in a way that will update it on a checkout (since git thinks there is no change). Even more weird when working on the same repository from both Windows and WSL.

Have much better experiences making sure all developers use proper IDEs that are properly configured. Configuration(s) embedded in the repository. Dealing with the occasional mishap when it happens, updating configurations and workflow recommendations (edit using any configured IDE instead of non-configured text editor).

Perhaps I'm the weird one.

RehanSaeed commented 2 years ago

I pretty much only use it for .sh, .cmd and .bat files. So very limited use case where it makes sense to do so. But agree, that if overused it might be cause for concern.

The trouble with relying developers to properly configure IDE's is that its not always possible e.g. if you're doing something on GitHub for example.

uluQulu commented 2 years ago

Tashakkur Muhammed, This changed my thought and want to used Git LFS now cos of the efficiency in big project. I did notice slowness of Git processes with binary files before and while reading your words, that was very clear. Now I have a custom .gitattributes with also Git LFS support as much as I could add.

Now I see Git LFS is the future.

bolligerm commented 1 year ago

The curly braces pattern matching syntax in the examples does not work. For example: *.{bat,[bB][aA][tT]} text eol=crlf It works only using this syntax: *.[bB][aA][tT] text eol=crlf

RehanSaeed commented 1 year ago

The curly braces pattern matching syntax in the examples does not work.

@bolligerm Not sure why its not working for you but it works for me.

DecimalTurn commented 1 year ago

@bolligerm Not sure why its not working for you but it works for me.

@RehanSaeed - I was also curious about this syntax with curly brackets as I couldn't find it mentioned in the docs or by looking at the code.

If I run the following in PowerShell on Windows:

mkdir "test-with-curly-bracket"
cd .\test-with-curly-bracket\
git init
echo "*.{bat,[bB][aA][tT]} text eol=crlf" > .gitattributes
dos2unix .gitattributes
git check-attr eol test.bat

I get : test.bat: eol: unspecified

However, with this version:

mkdir "test-without-curly-bracket"
cd .\test-without-curly-bracket\
git init
echo "*.[bB][aA][tT] text eol=crlf" > .gitattributes
dos2unix .gitattributes
git check-attr eol test.bat

I get : test.bat: eol: crlf

Based on that, it looks like a file with pathname ending with .bat doesn't match with the pattern using curly brackets.

dbnex14 commented 1 year ago

Thanks for the article but I still dont find much info on how to properly set .gitattributes for teams working on Windows, MacOS, Linux and technologies like Java, Angular Mind providing more explanation on that? It seem to be you are working on windows only

christian-schlichtherle commented 1 year ago

Very useful indeed! You could add a line for .xz files - these are artifacts of the xz compression utility.

RehanSaeed commented 1 year ago

@bolligerm Not sure why its not working for you but it works for me.

@RehanSaeed - I was also curious about this syntax with curly brackets as I couldn't find it mentioned in the docs or by looking at the code.

If I run the following in PowerShell on Windows:

mkdir "test-with-curly-bracket"
cd .\test-with-curly-bracket\
git init
echo "*.{bat,[bB][aA][tT]} text eol=crlf" > .gitattributes
dos2unix .gitattributes
git check-attr eol test.bat

I get : test.bat: eol: unspecified

However, with this version:

mkdir "test-without-curly-bracket"
cd .\test-without-curly-bracket\
git init
echo "*.[bB][aA][tT] text eol=crlf" > .gitattributes
dos2unix .gitattributes
git check-attr eol test.bat

I get : test.bat: eol: crlf

Based on that, it looks like a file with pathname ending with .bat doesn't match with the pattern using curly brackets.

This is syntax specific to git.

RehanSaeed commented 1 year ago

Thanks for the article but I still dont find much info on how to properly set .gitattributes for teams working on Windows, MacOS, Linux and technologies like Java, Angular Mind providing more explanation on that? It seem to be you are working on windows only

I work in a Windows and Linux environment and even have some Mac build machines for some open source projects. All working fine.

RehanSaeed commented 1 year ago

Very useful indeed! You could add a line for .xz files - these are artifacts of the xz compression utility.

I've not come across that one. Good to know.