Best practices for cross platform git config?

Question

Context

A number of my application user configuration files are kept in a git repository for easy sharing across multiple machines and multiple platforms. Amongst these configuration files is .gitconfig which contains the following settings for handling the carriage return linefeed characters

[core]
    autocrlf = true
    safecrlf = false

Problem

These settings also gets applied on a GNU/Linux platform which causes obscure errors.

Question

What are some best practices for handling these platform specific differences in configuration files?

Proposed solution

I realize this problem could be solved by having a branch for each platform and keeping the common stuff in master and merging with the platform branch when master moves forward. I'm wondering if there are any easier solutions to this problem?

Voiced

Related question about line endings & git: #1250432 – Accessible

Answer 1

I have reviewed that kind of config setting (crlf) extensively in the question:
distributing git configuration with the code.

The conclusion was:

• checkout/checking .gitattributes files
• list all types which explicitly need that kind of conversion.
  For instance:

*.java +crlf
*.txt +crlf
...

• avoid doing any kind of conversion of type of files which don't need it, because of the various side-effect of such a conversion on merges, git status, shell environment and svn import (see "distributing git configuration with the code" for links and references).
• avoid any 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.

Whitmore

Answer 2

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.

Angelita

some examples of headaches and sorrows would be a great addition to this answer. – Broiler

meh - most editors /can/ handle just \n, but default to platform line endings, as they should. – Analeptic

@Broiler if you're working with other developers and you're not all using the same autocrlf setting, you could end up with a ton of merge conflicts with files/changes that shouldn't actually conflict, just because the line endings are different. This is especially dangerous with the way that Git, be default, auto-commits merges it thinks were successful, and because diff editors can be set to treat whitespace as non-significant. Poor or non-existent code review by your dev team could cause you to reintroduce fixed bugs/cause dangerous code regressions. – Hindustani

you can change autocrlf with this command git config --global core.autocrlf false – Blackbird

I'm late, but I've got an example - Cygwin can't handle CRLF endings in shell scripts. That's okay normally, but when that script is the build script for half of the team's projects... lots of headaches from people thinking the build system was broken or the build was flawed when they'd just forgotten to run the Dos-to-Unix script. Finally changed the repo settings so that doesn't happen. – Camenae

Building docker imagens and any kind of Linux shell or DevOps has lots of headaches – Nostril

My embedded IDE generates files with CRLF and doesn't work if they are changed to LF. – Novia

Answer 3

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.

Beet

linux file endings are the default. It is the norm for git repositories. So the files are already in the correct format for the linux users. Your point is backwards. – Shennashensi