57

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.).

Improve this question
2
  • 2
    See also stackoverflow.com/questions/2332349/…: you may have an answer to add to this similar question. Commented Mar 2, 2010 at 9: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.) Commented Mar 2, 2010 at 23:08

4 Answers 4

Reset to default
95
+100

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 advocated for setting it to false by default, instead of true (which is the default value set by the msysgit installer of the time -- 2010!), 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.
Improve this answer
Sign up to request clarification or add additional context in comments.

11 Comments

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.
@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.
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: *.png -crlf placed after * +crlf (in the same .gitattributes file) should take care of that.
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.
|
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"
Improve this answer

3 Comments

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.
it doesn't work, on unix git doesn't sees the changes to the configuration file even with the link.
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";
3

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
Improve this answer

Comments

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
Improve this answer

1 Comment

why would hardlink be better?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.