Hello all,
I'm 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.
Thanks,
Nicolas.
+2
A:
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
2010-02-25 11:06:21
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
2010-02-25 11:43:35
it doesn't work, on unix git doesn't sees the changes to the configuration file even with the link.
nraynaud
2010-02-26 11:28:33
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
2010-03-19 21:05:41
+4
A:
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
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.
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
2010-03-01 06:52:12
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
2010-03-01 11:11:55
@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
2010-03-01 11:19:09
If I define * +crlfat 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
2010-03-01 13:37:15
@nraynaud: `*.png -crlf` placed *after* `* +crlf` (in the same `.gitattributes` file) should take care of that.
VonC
2010-03-01 14:53:29
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
2010-03-01 15:12:53
@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
2010-03-01 15:39:55
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
2010-03-01 17:51:38
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
2010-03-01 17:53:05
@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
2010-03-01 17:59:06
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
2010-07-29 16:34:13
@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
2010-07-29 17:23:39