0

The company I work for gave me the project of moving their java project from CVS to Git. For several reasons, they don't want to use another tool than Eclipse. So we're stuck with EGit.

I know it is possible to configure Eclipse to format code. But it seems like there is nothing that would prevent someone to use his own way of formatting the code.

So my question is, is it possible to refuse a commit with EGit if the code is not formatted correctly ? The reason behind this question is that we want to avoid conflicts due to the code format, which was a really big problem in CVS.

Thank you

Cyril
  • 83
  • 1
  • 4
  • Do you have a way of programatically determining whether a code is well-formatted or not? If so, perhaps look into "hook"s or something like that (I don't know myself, but I've been hearing about them). If you don't have a way of determining that, I'm afraid there is not much to do. Git doesn't (and won't) have a way to tell you whether your code style is correct or not (because there is no correct code style). – Shahbaz Jul 17 '12 at 17:39

3 Answers3

2

An alternative to checking the code during the commit is a scenario where gerrit is used as review system. The developers would commit their code to gerrit instead of directly to the git repository. Gerrit can then trigger a build job on a Jenkins/Hudson server and that build job can run CheckStyle or any other format checking tool you prefer.

On successful check Jenkins could then also verify the change and merge it into the git repository (most projects prefer Jenkins to only verify the correctness of the code, and a human still needs to review the code afterwards). Commits failing the check would remain in gerrit (and a mail would go to the developer).

The advantage of this approach is that you can do much more than only style checks for each commit, especially run unit tests, static code analysis and code coverage. The major drawback is that you have to set up some more tools than just a git hook.

Bananeweizen
  • 21,797
  • 8
  • 68
  • 88
2

I recommend setting the formatter and a save action to format code as a project-specific configuration. Then tracking the .settings directory in Git.

Because it's configured in the project and in version control, developers won't have to configure Eclipse themselves, it's automatic.

We have done this with several projects and if you do it from the start, you will never have any ill-formatted code or discussions about it.

If a developer is really reluctant and even goes as far as unchecking the project-specific formatter and using another one, maybe you should have a talk.

(By the way, a recommended option in the formatter is Never join already wrapped lines, because sometimes the formatter will do weird wrapping. This option makes it possible to have control over wrapping.)

robinst
  • 30,027
  • 10
  • 102
  • 108
  • We decided to choose this solution since it's easy to setup. If anyone decides to use another way of formatting, we'll just ask them to stop doing that. Thank you very much. – Cyril Jul 23 '12 at 08:10
1

If you know a way to determine if the code is formatted correctly you can implement this in the hook pre-commit

This hook should be placed in .git/hooks

git comes with a sample, called pre-commit.sample, it either in the hooks directory already or you can find it in the /usr/share/git-core/templates/hooks/ (On Ubuntu).

Peter van der Does
  • 14,018
  • 4
  • 38
  • 42