How to accommodate multiple coding styles? (git vs. IDE)

I am collaborating on a git-sourced, maven-managed Java project with differing code styling preferences with users using multiple IDE’s (note 1).

Is there a tool or IDE configuration that will allow code to be viewed and edited using style-1, but committed to SCM using style-2?

  • Enforcing coding style with pre-receive Git hook
  • Where to hook a coding convention script?
  • Which style do you use for your commit messages? Technical or feature-based?
  • Reject commit in Git if Java code style isn't correct
  • Git: pre-receive hook with PHP_CodeSniffer
  • Ensure coding-style during a git commit
  • My research points me to ‘no’, but a solution combining git hooks and Checkstyle/jrefactory might be possible.

    So if ‘no’ to above, is there a tool/process that will perform the TBD process actions below?

    The checkout process flow for User1 would be:

    1. git pull
    2. TBD process formats code to User1 style-1
    3. User1 works in their preferred IDE with style-1 settings

    The commit workflow for User1 would be:

    1. User1 is ready to commit/push code
    2. TBD process formats code to standard format style-standard
    3. git push

    Note 1: multiple IDE’s = Eclipse, IntelliJ, Netbeans.

    Note 2: My question differs from this question in that I’d like to focus on an IDE-related solution, since forcing the minority of standards-divergent users is probably a more efficient solution.

    Note 3: Acknowledging that this shouldn’t be done for best-practices-reasons. However, if you grant that it’s time expect more flexibility from our IDEs and SCMs, this question is intended to explore those solutions.

  • Rstudio greyed out Git commands and (No branch)
  • How can I make a a subdirectory in my GitHub project into a new repository?
  • SSH Public key denied on “git clone” command
  • How to get first and last commit from git from a user
  • Vim: highlight changes compared to latest repo commit
  • Git is not showing all branches on local
  • 2 Solutions collect form web for “How to accommodate multiple coding styles? (git vs. IDE)”

    First of all, you really shouldn’t do that. Codestyle wars are bad for any project, and it is best to decide upon one codestyle that everybody must use. It is simple to configure IDEs to automatically apply the specified codestyle at every filesave, so the developers don’t have to write code in the target codestyle themselves, they can let the IDE do that for them. True, this doesn’t solve the fact that they’ll have to read code in a codestyle they don’t yet like, but it’s a lot safer than having invisible automatic code changes; that’s a major source of bugs.

    Maybe you can use Eclipse’s code formatter from the command line to apply a different codestyle. You’d have to set up git hooks, make sure everybody has Eclipse available, and provide the proper configuration files for their preferred codestyle. You’d need hooks both for post-checkout and pre-commit, one to set up the user’s codestyle, the other to commit in the central codestyle. To go one step further, you can play with the index to add the formatted code so that it doesn’t include style differences in git diff (although they will show up in git diff --staged).

    Again, you shouldn’t do that.

    I agree with Sergiu Dumitriu in this not being a very good idea. But still git provides exactly what you are looking for. Even though this will only work if your central coding style is very well defined and strictly followed. Here’s how it works:

    Git provides smudge/clean filters. They allow you to pass all code through a so-called “smudge” filter on checkout and reverse that with a “clean” filter when code is added to the staging area. These filters are set in .gitattributes, and there is a repository-local version of that file available in .git/info/attributes.
    So you set your smudge filter to a tool that will change the code to your personal coding style on checkout:

    smudge filter

    And your clean filter will convert the code back to the central coding style on checkin (more precisely: when file are staged):

    clean filter

    It is very important, that smudge -> clean is a no-op / generates the original file again. Otherwise you will still check in format changes every time you change a file.

    Using smudge and clean filters will retain all the functionality of git (including git diff etc). You can find the full docu in git help attributes

    Git Baby is a git and github fan, let's start git clone.