GIT CRLF to LF - git parent repo on UNIX and clones on both windows and unix

This question is somewhat similar to my other question, make sure files are converted CRLF into LF in an update hook- is there a performance hit?

So here is what am looking for with the below architecture. 1. MY parent repository (bare and data) is on a UNIX machine. 2. I can clone my repository in a UNIX machines. 3. I can clone my repository in a Windows machines using samba to access my parent repo.

How can i take care of CRLF issues if

1. The user creates clones in UNIX, maps it using samba into windows drive, the modifications are done in Windows which create a CR/LF character pair as the EOL. If 开发者_JAVA百科the users come back to Unix and commits and pushes. How does GIT take care? or do we need to have some hooks in place?

2. Same as above, but the file format exceeds 8000 characters per line - a lot. Is this treated as a ASCII file with the CR stripped out on commit?

3. Variation of 2, but it's a binary file which has an ASCII header. Is this going to inadvertently have CR/LF's changed to LF?

---

The two places to look are Git-config and git-attributes.

You will need to decide on your local standard, which will depend on your other external programmes, particularly corporate source control standards, and any tools that expect a particular format.

The manual pages feel a little confused at first and second reading. You need to note the cryptic codings such as 'working directory' means 'checked out' files, etc.

The 'default' is to 'normalise' which means that files committed to the repo would have LF endings. Then with the right setting you can have checked out files as [always] LF, or [always] CRLF or chosen based on your [local] platform.

I've no idea about the long lines, but I expect that git is quite happy with them.

For the special files with text headers etc, the git attributes file allows you to define file type and path specific check-in and check-out protocols (examples in the man pages.

PS I've just been stuck on this myself with Matlab's *.m eol=LF ;-)