Reputation:
I'm mastering a development team where everyone worked with Eclipse and the same formatting settings.
Now some of the developers have reasons to switch to other IDEs, which format source code differently. So, when they now push to the git origin repo, git notices a a lot of cosmetic differences. Unfortunately, this is a big problem for some of the developers to get their head around.
Is there a way to get git - maybe by using hooks - to reformat everything on push or preferably commit, so the code in the repo is always formatted IDE independently?
I'm assuming we are not the first team in git-history to have that problem, so I hope there is a prefab solution or at least some best practices.
Upvotes: 7
Views: 4328
Reputation: 18520
The only way to do this reliably is on the server side (client-side hooks are not automatically set up during clone for security reasons, so if you do it on the client side as suggested in one of the comments, each developer has to manually set up that hook once).
There, you can, in theory, manipulate the received updates... but it's a fairly complicated thing to do. The actual problem, though, is that once it's done, you have your own, untouched commits locally and there are modified commits on the server – this is asking for trouble. If you were to do a pull/merge now, git would combine the untouched history with the modified history and suddenly you have all of the commits twice.
If you want to make sure only properly formatted code ends up in the repository, it's much easier and causes less problems if you reject incorrectly formatted code. This can be fairly annoying in practice, of course, but that's the trade-off you have to decide about.
Suppose you can get your developers to do that local hook setup thing, then a local pre-commit hook will almost certainly be easier to write and cause less hassle in practice – but it can be bypassed in various ways, so there are no ironclad guarantees.
Upvotes: 5