4 ms·

Can’t you just set up a linter/formatter to your style, apply it to your style when editing and on save set it to the project style?

kevin_thibedeau 6y ago
It fucks up the diffs in the codebase.
- michaelmior 6y ago
  How so? If the canonical format is applied every time you save, you'll always be doing a diff with files using the same format. Of course, it does mean the code in the diffs may not be in your preferred format.
  - kevin_thibedeau 6y ago
    If you want to diff against anything in the past you get a bunch of formatting noise that occludes real changes.
    - michaelmior 6y ago
      If you're talking about moving from a codebase that did not use a consistent formatting style or a style that did not match the auto formatter configuration, sure. I was assuming a case where automatic formatting was done from the start.
    - mcgoo 6y ago
      This is something that keeps coming back to me either as a feature or as a product of some kind - a tool that can stop this from getting in our way. The simplest and safest would be to apply the formatter to both the old and the new copy before diffing it. It ceases to be the actual difference at that point, but there are definitely two distinct use cases for diffs - one for humans to read and one for the machine to apply. The other case that would be amazing but even more of a stretch would be to rewrite the entire history. It seems like there is a spot for "different views of history" and you could do a no-difference merge to join the to histories as of now so that the actual history did not get lost. As I write this, it starts to sound like just a caching system for the idea above. This needs a highly reliable formatter of course... I have on occasion had code broken when formatting.
    - dtech 6y ago
      Usually when introducing such a tool you do 1 commit that reformat the whole codebase to the new style and then automatically enforce it.
      - erichurkman 6y ago
        And in those large reformat commits, add a file like `.git-ignore-revs-file` that is checked in, so you can configure git to ignore that revision and pretend it never existed: [blame] ignoreRevsFile = ".git-ignore-revs-file" markIgnoredLines markUnblamableLines
        dtech 6y ago
        That's an incredibly useful trick to know
    - peterstensmyr 6y ago
      Git has an option to ignore certain commits when doing a git blame, —ignore-revs. You can also point it to a file with —ignore-revs-file <file>. You can configure this per project with git config ignoreRevsFile .git-blame-ignore-revs. After doing this, you get nice diffs AND nice looking code. The price to pay is that every developer has to run one git command locally.

kevin_thibedeau 6y ago

It fucks up the diffs in the codebase.

michaelmior 6y ago
How so? If the canonical format is applied every time you save, you'll always be doing a diff with files using the same format. Of course, it does mean the code in the diffs may not be in your preferred format.
- kevin_thibedeau 6y ago
  If you want to diff against anything in the past you get a bunch of formatting noise that occludes real changes.
  - michaelmior 6y ago
    If you're talking about moving from a codebase that did not use a consistent formatting style or a style that did not match the auto formatter configuration, sure. I was assuming a case where automatic formatting was done from the start.
  - mcgoo 6y ago
    This is something that keeps coming back to me either as a feature or as a product of some kind - a tool that can stop this from getting in our way. The simplest and safest would be to apply the formatter to both the old and the new copy before diffing it. It ceases to be the actual difference at that point, but there are definitely two distinct use cases for diffs - one for humans to read and one for the machine to apply. The other case that would be amazing but even more of a stretch would be to rewrite the entire history. It seems like there is a spot for "different views of history" and you could do a no-difference merge to join the to histories as of now so that the actual history did not get lost. As I write this, it starts to sound like just a caching system for the idea above. This needs a highly reliable formatter of course... I have on occasion had code broken when formatting.
  - dtech 6y ago
    Usually when introducing such a tool you do 1 commit that reformat the whole codebase to the new style and then automatically enforce it.
    - erichurkman 6y ago
      And in those large reformat commits, add a file like `.git-ignore-revs-file` that is checked in, so you can configure git to ignore that revision and pretend it never existed: [blame] ignoreRevsFile = ".git-ignore-revs-file" markIgnoredLines markUnblamableLines
      - dtech 6y ago
        That's an incredibly useful trick to know
  - peterstensmyr 6y ago
    Git has an option to ignore certain commits when doing a git blame, —ignore-revs. You can also point it to a file with —ignore-revs-file <file>. You can configure this per project with git config ignoreRevsFile .git-blame-ignore-revs. After doing this, you get nice diffs AND nice looking code. The price to pay is that every developer has to run one git command locally.