How are you enforcing git behavior, including locally (particularly on Windows)?

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.

Answer

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 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. 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? 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 What did you end up doing to solve your problem ? @Newtopian - higher priority stuff has pulled me off the project. At this point I'm thinking we'll just roll with the defaults (especially since I've already had some devs convert projects to git and I'm 99% sure they committed lf).

Any time the project gets checked out on a windows box it'll have crlf so it's not that big a deal. I'm no git expert, but could you use one of these hooks to run the file through dos2unix?