<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-04-25T05:15:12.017Z
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.
ndarwincorn
CC BY-SA 3.0
2017-04-26T12:18:56.000Z
We are using typescript, github and jenkins. Typescript has a nice ecosystem for this type of thing.
avi
CC BY-SA 3.0
2017-04-23T09:19:15.073Z
2017-04-26T12:17:54.193Z
2017-04-26T12:17:54.193Z
avi
<p>You could use <a href="https://git-scm.com/docs/gitattributes" rel="nofollow noreferrer">per repository config</a> 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.</p>

<p>You can further enforce this through <a href="https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks" rel="nofollow noreferrer">hooks</a> 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.</p>

<p>Using templates in your <a href="https://git-scm.com/docs/git-init" rel="nofollow noreferrer">git init</a> you can ensure that your repos are created equals with all the gitignore, gitattributes etc files just the way you want them to be.</p>

<p>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 <a href="http://ndpsoftware.com/git-cheatsheet.html" rel="nofollow noreferrer">visual cue sheet</a> helped a bit explain which command had what effect to which part.</p>

<p>Hope this helped a bit.</p>

CC BY-SA 3.0
2017-04-26T13:48:56.317Z
2017-04-26T13:48:56.317Z
Newtopian
<p>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. </p>

<p>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 <strong>your</strong> 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.</p>

<p>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 <em>your</em> repo with <em>their</em> potentially breaking stylistic choices.</p>

CC BY-SA 3.0
2017-04-21T02:12:02.440Z
2017-04-21T02:12:02.440Z
hvindin
<p>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.</p>

<p>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.</p>

<p>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.</p>

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

<p>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.</p>

CC BY-SA 3.0
2017-04-17T20:23:51.537Z
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
CC BY-SA 3.0
2017-04-17T20:35:45.800Z
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.
Dave Swersky
CC BY-SA 3.0
2017-04-17T21:24:50.740Z
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?
ndarwincorn
CC BY-SA 3.0
2017-04-18T04:43:27.767Z
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
CC BY-SA 3.0
2017-05-04T13:36:02.137Z
What did you end up doing to solve your problem ?
Newtopian
CC BY-SA 3.0
2017-05-05T19:48:19.793Z
@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.
ndarwincorn
CC BY-SA 3.0
2017-05-22T04:01:54.617Z
I'm no git expert, but could you use one of these hooks to run the file through [dos2unix?](http://www.linuxcommand.org/man_pages/dos2unix1.html)
James Shewey
<git><scm><windows>
How are you enforcing git behavior, including locally (particularly on Windows)?
ndarwincorn
# How are you enforcing git behavior, including locally (particularly on Windows)?

(Asked by: username_0 on 2017-04-17)

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. Husername_5ng 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.

**Tags:** git, scm, windows

> **Comments:**
> **username_1**: 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  
> **username_2**: I agree with username_1, 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.  
> **username_0**: 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 @username_1...could you elaborate on those downsides you see to client-side?  
> **username_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  
> **username_3**: What did you end up doing to solve your problem ?  
> **username_0**: @username_3 - 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.  
> **username_4**: I'm no git expert, but could you use one of these hooks to run the file through [dos2unix?](http://www.linuxcommand.org/man_pages/dos2unix1.html)  

---

## 3 answers

### Answer by username_6 on 2017-04-21. Score: 6 | Accepted answer

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 by username_5 on 2017-04-23. Score: 4

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.

> **Comments:**
> **username_0**: 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.  
> **username_5**: We are using typescript, github and jenkins. Typescript has a nice ecosystem for this type of thing.  

---

### Answer by username_3 on 2017-04-26. Score: 3

You could use [per repository config](https://git-scm.com/docs/gitattributes) 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](https://git-scm.com/book/gr/v2/Customizing-Git-Git-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](https://git-scm.com/docs/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](http://ndpsoftware.com/git-cheatsheet.html) helped a bit explain which command had what effect to which part.

Hope this helped a bit.


---

