1

I'm using git across a number of platforms, and with containers, and am mounting filesystems between Windows and Linux containers. All the development tools I use can handle whatever line endings the source code has, silently, and sensibly. Except git.

I am finding git - commad line and desktop app - will transform line endings between Windows and Linux formats (CRLF ad LF). I don't want it to do that. I just want git to handle the files as supplied, and not try to second-guess how they are going to be used by transforming them. The transformed line endings is causing havoc. I create the files with LF line endings, and that is how I want them to stay, always, everywhere.

How can the git tools be told to leave the line endings alone? All documentation I have been able to find describe how to set various rules for different types of transforms for different tyoes of files within a specific repository. This is a function of my tools, not the repository. How do I set it for the tools to leave my file formatting well alone?

Improve this question

1 Answer 1

Reset to default
3

Easiest way is to add this into .gitattributes:

* -text

That should do. That is to tell git: I will take care of line endings.

There's important information in the comments (not necessarily from me) so make sure to read them.

Improve this answer
Sign up to request clarification or add additional context in comments.

12 Comments

So that option for the repository says "do not normalise any file being checekd in". Presumably all developers with this repo checked out under Windows will need to discard their work files and clone again, othwerwise they may end up committing Windows line endings that they have checked out. I must make this change in a clone of the repo under a linux environment to ensure the files are "frozen" with Linux line endings? Is there no way I can set this for my tools, i.e. for my version of git on my machine? Or does is this always a property of the repository?
@Jason What you can write in .gitattributes, you can instead write into .git/info/attributes and it will affect only that clone of the repository.
As @j6t salid, .git/info/attributes will work just as well and it won't be pushed/pulled.
@Jason: make the initial clone with -n (short for the longer --no-checkout, which you can also use). Then edit the .git/info/attributes file as desired, and then run git checkout. If you forget, simply remove the entire work-tree and run git checkout HEAD -- . or git reset --hard HEAD, for instance.
Note that there are personal and system-wide .gitattributes files. Your personal one is in $XDG_CONFIG_HOME/git/attributes or $HOME/.config/git/attributes. The system one is in $(prefix)/etc/gitattributes, where $(prefix) is a Git-compile-time option. The system and user files have lower precedence than any committed .gitattributes, though, so if someone has a committed .gitattributes, that will override your own user one. The .git/info/attributes file is the highest priority, fortunately.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.