![]() I once had to merge a huge feature branch. We use Eclipse along with its egit plugin for development. Our development machines are Windows workstations while test and production servers are linux/unix. We are mostly dealing with java projects, but our repositories contain a bunch of shell scripts for automation, testing and stuff like that. This would cause git to commit line endings into its object database exactly as they appear in the workspace (the only setting letting Windows’ CRLF into git’s object database). The only tocrlf setting to avoid at all cost, at least on windows, is false. Going with the input setting also shouldn’t cause too much trouble: in this case, git checks line endings out into the workspace as they are in the object database without changing them, but still makes sure to replace any Windows CRLF line endings with linux LF when committing to git’s object database. On Windows, it seems to be recommended setting it to true, causing git to use Windows CRLF in the workspace and auto-converting line endings to LF when committing to git’s object database. ![]() As every git setting, it can be specified per-repository or globally (per OS user). The most important bit in this case is the tocrlf setting. It also helped me find the cause of the issue, so props to them! ![]() While investigating the issue, I found the excellent Mind the End of Your Line article over at , which explains how line endings should be handled in the first place. Well, turns out: it is, and it is quite often. If you know git, you’re aware of the line ending settings and that line endings basically should never be an issue. ![]() Recently, our team at work stumbled upon a strange behavior in their Git projects: there were files with Windows CRLF line endings checked into the git repository. ![]()
0 Comments
Leave a Reply. |