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

Question

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 1

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.

Answer 2

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.

Answer 3

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.