A number of my application user configuration files are kept in a git repository for easy sharing across multiple machines and multiple platforms. Amongst
I have reviewed that kind of config setting (crlf
) extensively in the question:
distributing git configuration with the code.
The conclusion was:
*.java +crlf *.txt +crlf ...
git status
, shell environment and svn import
(see "distributing git configuration with the code" for links and references).crlf
conversion altogether if you can.Now, regarding the specific issue of per-platform settings, branch is not always the right tool, especially for non-program related data (i.e; those settings are not related to what you are developing, only to the VCS storing the history of your development)
As stated in the question Git: How to maintain two branches of a project and merge only shared data?:
your life will be vastly simpler if you put the system-dependent code in different directories and deal with the cross-platform dependencies in the build system (Makefiles or whatever you use).
In this case, while branches could be use for system-dependent code, I would recommend directory for support tools system-dependent settings, with a script able to build the appropriate .gitattributes
file to apply the right setting depending on the repo deployment platform.
Never turn autocrlf
on, it causes nothing but headaches and sorrows.
There's no excuse to use \r\n
on windows, all decent editors (by definition) can handle \n
.
I think you should have the .gitconfig depend on the operating system the user is using. Windows users don't need autocrlf at all while Linux users do. E.g. save the text files with crlf and have Git convert the files automatically back and forth for the Linux users.
You might also want to check .gitattributes, which allows you to define which files are converted and which are not. If you have the configuration files in just one place, you could define that the conversion is only done in that directory just to be on the safe side.