46

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 forgetting to set it by hand.

How do I set this up?

I'm a bit concerned by all this negativity against autocrlf. Why not remove this feature if it doesn't work? Either the makers of this feature are misunderstood or they made a failed experiment with it and it should be removed to stop more people from wasting their time (reading the obscure man page, asking questions, people answering those questions etc.).

random
  • 9,324
  • 10
  • 63
  • 77
nraynaud
  • 4,404
  • 6
  • 37
  • 50
  • 2
    See also http://stackoverflow.com/questions/2332349/best-practices-for-cross-platform-git-config: you may have an answer to add to this similar question. – VonC Mar 02 '10 at 09:13
  • 2
    thanks, but I'm a bit concerned by all this negativity against autocrlf, why not remove this feature if it doesn't work? Either the makers of this feature are misunderstood or they made a failed experiment with it and it should be removed to stop more people from wasting their time (reading the obscure man page, asking questions, people answering those questions etc.) – nraynaud Mar 02 '10 at 23:08

4 Answers4

80

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)

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.
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • Thanks for your answer. I think I get confused messages regarding autocrlf. I've read somewhere that git does commit only in \n mode and that it's good. some of my developers are using windows, and since everybody in the world can read crlf, I just think crlf for everybody is the best. BUT we have to accomodate git who seems to only like cr. What do you think ? I'm reviewing the attribute idea, I ruled it out before because my understanding was that it applies works on a per file basis, not repository-wide. Maybe I'm mistaken. – nraynaud Mar 01 '10 at 11:11
  • 2
    @narynaud: personally, I like '`\n`', and I like not changing anyhting regarding eol. But should you enforce one eol style, `.gitattributes` is really interesting because you can apply it to the all repository, or only to specific parts within the repo. – VonC Mar 01 '10 at 11:19
  • If I define * +crlf at the project root, I suppose I'm going to hell with my png pictures ? How can I say "if you think it's text then do crlf otherwise, do binary". I'd like to avoid making the hard decision by myself, the system is good at this guessing and debugging an error would be really difficult. – nraynaud Mar 01 '10 at 13:37
  • @nraynaud: `*.png -crlf` placed *after* `* +crlf` (in the same `.gitattributes` file) should take care of that. – VonC Mar 01 '10 at 14:53
  • 1
    That's exactly what I want to avoid. because I'll forget to add the .gif or one day one co-worker will add a new file format and don't see he destroyed it at the commit ("it worked on my computer", and tests don't see visual destruction of a website). To me it looks like this is digging in a bad solution. – nraynaud Mar 01 '10 at 15:12
  • @nraynaud: right, so why don't you make the opposite and only specify the specific types where you *need* an auto-conversion, leaving all the other untouched? The idea remains: you can specify some kind of format standard in a `.gitattributes` file (pushed/pulled), as opposed to local config settings. – VonC Mar 01 '10 at 15:39
  • I think it's the same problem on the "textfile" side. I wonder if I shouldn't ditch CRLF alltogether, but I don't really know how the Windows editors will react. – nraynaud Mar 01 '10 at 17:51
  • BTW I give you the points, I think that you're the closest from a solution. It looks like what I would really need is a patch to be committed into git. – nraynaud Mar 01 '10 at 17:53
  • @nraynaud: "I think it's the same problem on the "textfile" side": not quite, as a new text type not taken into your account wouldn't trigger a "destruction" of its content. "I wonder if I shouldn't ditch CRLF alltogether": I sure did ;) And all of my recent Windows editor (Notepad++, Scite, EditPad Pro, ...) deal with those files just fine. – VonC Mar 01 '10 at 17:59
  • This is exactly the information I was looking for. However, I have a question about how you would implement it. Say I wanted to get enforce the lf encoding on only .rb files, how would I configure my .git/config file and the project root .gitattributes file? Wouldn't it work if .git/config had `core.autocrlf = false` and .gitattributes has `*.rb text`? – vrish88 Jul 29 '10 at 16:34
  • @vrish88: I am not sure because I haven't tested it directly, nut that is the general idea. Note: `text` means it will follow the `core.eol` configuration variable for all text files (in your `.git/config`). – VonC Jul 29 '10 at 17:23
5

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"
Jason Axelson
  • 3,793
  • 3
  • 42
  • 50
  • That's a smart idea, we have mixed Windows/Mac/linux. But maybe git can use the windows link stuff, I'll try to google that. – nraynaud Feb 25 '10 at 11:43
  • it doesn't work, on unix git doesn't sees the changes to the configuration file even with the link. – nraynaud Feb 26 '10 at 11:28
  • 2
    Well if you're on unix it should work the other way around mv .git/config git-config; cd .git; ln -s ../git-config config; cd ..; git add git-config; git commit -m "Now tracking git config file"; – Jason Axelson Mar 19 '10 at 21:05
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
kenorb
  • 118,428
  • 63
  • 588
  • 624
0

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
METAJIJI
  • 327
  • 1
  • 9