I'm taking point on moving this .NET shop from svn to git, and have identified some ancillary issues I'd like to have a solution for before we flip the switch.

The one I'm asking about in particular in this question is line-ending enforcement. By default git for windows installs with the 'checkout crlf, commit lf', which won't work for a bunch of source that is (as far as I'm aware) exclusively comprised of crlf endings.

I don't know that I'd blindly trust any given dev to configure this correctly even given instruction, so I'm considering one (or both) of the following but was curious if anyone here had gone another route.

  • A pre-commit hook that checks for any lf line endings (or maybe all lf line endings), and rejects in that event.
  • An install script distributed to devs that populates the global config with the 'as-is, as-is'.

P.S. While writing this it occurred to me that the initial conversion from svn to git could commit the default way and as long as people stuck to the default that would be pretty seamless as well. Having been a dev using git in a .NET shop that installed git with the non-default 'as-is, as-is', I've created my own issues there too (they'd all rolled default prior to my arrival). So I'm still leaning towards some sort of enforcement mechanism.

  • 2
    With a pre receive hook server side this should be handable (ensure crlf endings and fail if not), with an update hook you should be able to update pre-merge also. Which type of git server are you using ? If this has to be done workstation side, a Configuration manager can be the way to go, but harder and with a bunch of downsides. Last resort is linting on CI and fail to enforce people to follow procedures
    – Tensibai
    Commented Apr 17, 2017 at 20:23
  • 1
    I agree with Tensibai, and would add that the option you select should be based on how strictly you believe this should be enforced. Pre-commit hooks for strict enforcement, linting for post-commit compliance reporting. Commented Apr 17, 2017 at 20:35
  • Thanks Dave, my rationale for client-side/stricter enforcement is it would entail less work overall for me and catch the errors sooner. Not going to CM the devs' workstations but the dev servers are all in DSC so adding that will be trivial. Edit: Thank you as well @Tensibai...could you elaborate on those downsides you see to client-side? Commented Apr 17, 2017 at 21:24
  • 1
    Mainly if you enforce a global hook client side you may end up preventing work on projects needing lf endings. And you have to set it up in some way, you can't be sure everyone will follow the correct setup. I'm sure there is other footguns I don't think about right now
    – Tensibai
    Commented Apr 18, 2017 at 4:43
  • What did you end up doing to solve your problem ?
    – Newtopian
    Commented May 4, 2017 at 13:36

3 Answers 3


To answer the question of how to enforce something locally, you can't without doing some very heavy lifting around managing and enforcing the state of every developers workstation, and I'm usually of the opinion that developers should probably be local admins on their development machine because if they aren't then they will just spend their time figuring our how to get those privileges anyway.

And that's probably because you shouldn't need to care about the state of local configuration when using distributed version control. You should only care about the state of your configuration. Assuming you are using git as a centralised version control system, because that's what basically everyone does anyway because its easiest, then let's just assume that "your" configuration is the copy of code saved on the central server.

If this is the case then you shouldn't accept merges that, as you mentioned, break crlf/lf line endings. So you enforce that when some other client tries to push changes you with server side logic that rejects the request to pollute your repo with their potentially breaking stylistic choices.


We require a review process using Pull requests in github onto our main dev or master branches. During that review process, we will mark pull requests as requiring changes if many files have white space or line ending differences, and insist that they follow the formatting of the dev or master branch they are making the pull request for.

There are also some nice tools depending on which languages you use and which CI tools you use, which can, during the build process or pull request step auto format the code based on rules that you set up. That also helps with keeping code looking consistent and minimizing formatting issues when committing code.

  • Would you care to elaborate on the tooling you're using? Given that there are a number of ways to accomplish this, and we've got our own but have yet to really implement them that way, I'm curious how you're solving that. Commented Apr 25, 2017 at 5:15
  • 1
    We are using typescript, github and jenkins. Typescript has a nice ecosystem for this type of thing.
    – avi
    Commented Apr 26, 2017 at 12:18

You could use per repository config to override the user's config on a per-repository basis. When done on the repo considered to be the central source it should propagate with clones and pulls to other repos including local ones thus overriding centrally the local config.

You can further enforce this through hooks in your central repo to check that file endings are what they supposed to be and reject the merge/push should it not be kosher. However these hooks will not clone with the repo, least not directly but this is not necessary since the rules only really need to be enforced on the central repo.

Using templates in your git init you can ensure that your repos are created equals with all the gitignore, gitattributes etc files just the way you want them to be.

Last thing, not directly related to your question, I found the biggest friction point when taking svn saavy team to a git based workflow what to get them used to the extra repo in the middle. I found that this visual cue sheet helped a bit explain which command had what effect to which part.

Hope this helped a bit.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.