Distributing git configuration with the code

Question

In trying to standardise the platform for the developers, one of my needs would be to commit the .git/config so that everybody have the same CRLF config without

Answer 1

If you're using a Unix family operating system I would recommend just creating a symbolic link.

ln -s .git/config git-config
git add git-config
git commit -m "Now tracking git config file"

Answer 2

The .git/config can be overridden locally by ~/.gitconfig.

So as part of the build, Makefile or provision script, you can propose the change for users into their ~/.gitconfig, or load local script .gitconfig via git config.

For example, create new .gitconfig with some settings, and load it by:

git config --local include.path "/path/to/.gitconfig"

or ask users to have in their ~/.gitconfig these lines:

[include]
    path = .gitconfig

If you're using Vagrant as part of your code distribution, you may load git config from Vagrantfile by:

system('GIT_TRACE=1 git config --local include.path "$(git rev-parse --show-toplevel)/git/gitconfig"');

then commit your git config in git/gitconfig, so each time when users run provisioning of their VM, this file would be loaded automatically for their git on host machine (e.g. to enforce core.filemode to be disabled, so Windows won't have any issues with file permissions).

---

To force line endings for users, you should use .gitattributes instead which should work out-of-box. Sample syntax to use Unix-like line endings (LF):

# Drupal git normalization
# @see https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
# @see https://www.drupal.org/node/1542048

# Define text file attributes.
# - Treat them as text.
# - Ensure no CRLF line-endings, neither on checkout nor on checkin.
# - Detect whitespace errors.
#   - Exposed by default in `git diff --color` on the CLI.
#   - Validate with `git diff --check`.
#   - Deny applying with `git apply --whitespace=error-all`.
#   - Fix automatically with `git apply --whitespace=fix`.

*.css     text eol=lf whitespace=blank-at-eol,-blank-at-eof,-space-before-tab,tab-in-indent,tabwidth=2
*.html    text eol=lf whitespace=blank-at-eol,-blank-at-eof,-space-before-tab,tab-in-indent,tabwidth=2 diff=html
*.js      text eol=lf whitespace=blank-at-eol,-blank-at-eof,-space-before-tab,tab-in-indent,tabwidth=2
*.json    text eol=lf whitespace=blank-at-eol,-blank-at-eof,-space-before-tab,tab-in-indent,tabwidth=2

# Auto-detect text files, ensure they use LF (not recommended).
#*         text=auto eol=lf

# Define binary file attributes.
# - Do not treat them as text.
# - Include binary diff in patches instead of "binary files differ."
*.gz      -text diff

Answer 3

I have always found the autocrlf config property problematic. (as expressed in my answer Git 1.6.4 beta on Windows (msysgit) - Unix or DOS line termination)

• it not only make some merges tricky
• it can vary depending on the shell used within one environment
• it also has issue with git status
• and with svn import.

Note: msysgit issue 538 for setting it to true (which is the default value set by the msysgit installer), but I am not convinced.

I would prefer one of the three following solutions for:

• configuring one end-of-line style
• making that configuration propagate through the different Git repos

First: git config --global core.autocrlf false
Then:

1. Using the new config setting core.eol (1.7.2+)

Sets the line ending type to use in the working directory for files that have the text property set.
Alternatives are 'lf', 'crlf' and 'native', which uses the platform's native line ending.
The default value is native.

2. a checkout/checking .gitattribute. See gitattributes man page: crlf or core.autocrlf is the way to record in a .gitattributes file what is was previously a local config attribute.

You can add checkout/checkin attributes like:

*.vcproj    text eol=crlf
*.sh        text eol=lf

3. a git attribute filter driver which can:

• enforce any kind of formatting standard you may want to set
• apply those standards to certain files/directories
• be recorded as a config file (.gitattributes) able to be pushed anywhere.

Answer 4

May be a better way to use the hardlink:

In *nix or OS X system:

ln .git/config git-config
git add git-config
git commit -m "Now tracking git config file"

In Windows on NTFS-filesystem System:

mklink /H git-config .git\config
git add git-config
git commit -m "Now tracking git config file"

But we must remember that when cloning project to apply the settings to perform the reverse procedure:

In *nix or OS X system:

git clone FROM_PROJ_URL
rm .git/config
ln git-config .git\config

In Windows on NTFS-filesystem System:

git clone FROM_PROJ_URL
del .git\config
mklink /H .git\config git-config