4 ms·

"checkout project, reformat all source files, commit"

by itronitron 2y ago

breckenedge 2y ago
lol I love when people do this and it and now whenever I `git blame` their name shows up.
- jakub_g 2y ago
  FWIW, git now has options to ignore such commits. In a big codebase each big codemod sha should be added to the blame ignore file .git-blame-ignore-revs. It's supported by GitHub out of the box https://www.stefanjudis.com/today-i-learned/how-to-exclude-commits-from-git-blame/ https://www.stefanjudis.com/today-i-learned/how-to-exclude-c...
- clawlor 2y ago
  Agreed, this is quite annoying, but there is a workaround. You can tell blame to ignore commits like this, through a config option blame.ignoreRevsFile or similar CLI option. Not the most convenient perhaps, but it’s something. I believe GitHub also supports this, though you may have to request it to be enabled in your repository. Given this, I tend to prefer a single, formatting-only commit when introducing formatting standards to an existing codebase. Otherwise, it’s difficult to take advantage of QOL features like auto formatting in your editor, or other formatting tools which tend to operate on entire files. Then PRs end up being mixed with formatting changes, which adds friction to the review process.
bornfreddy 2y ago
Sure. Of course you can't commit to the main branch and your commit will never pass code review (which is a requirement for merging), let alone the automated tests in CI that apply formatting and fail if anything is not formatted as it should be. These safeguards save so much time that there should be no excuse for not having them.
- alexvitkov 2y ago
  Not wanting pipelines to fail because someone put an extra space after the line, or because someone's text editor didn't put a new line at EOF, or put a unicode BOM or whatever is a pretty good reason not to have this "safeguard".
jbaber 2y ago
I've had innocents' IDEs do this to them. Fortunately it results in pull request rejected, not commit to master.
nickysielicki 2y ago
Just to be clear, the argument for this has nothing to do with how the code looks and has everything to do with how you can swallow a pill, once, and in exchange you get clean rebases forever. You can hide the commit from blame consideration.
- devnullbrain 2y ago
  I've seen changes like this drag out over a year because the product had so many permutations that thoroughly testing any change was an exercise in futility. I've also seen changes like this fail to happen just due to a lack of cultural desire to make things happen. The first one is more forgivable - sometimes that's just the problem space. But neither of them are conducive to fulfilling working environments.

"checkout project, reformat all source files, commit"

breckenedge 2y ago

lol I love when people do this and it and now whenever I `git blame` their name shows up.

jakub_g 2y ago
FWIW, git now has options to ignore such commits. In a big codebase each big codemod sha should be added to the blame ignore file .git-blame-ignore-revs. It's supported by GitHub out of the box https://www.stefanjudis.com/today-i-learned/how-to-exclude-commits-from-git-blame/ https://www.stefanjudis.com/today-i-learned/how-to-exclude-c...
clawlor 2y ago
Agreed, this is quite annoying, but there is a workaround. You can tell blame to ignore commits like this, through a config option blame.ignoreRevsFile or similar CLI option. Not the most convenient perhaps, but it’s something. I believe GitHub also supports this, though you may have to request it to be enabled in your repository. Given this, I tend to prefer a single, formatting-only commit when introducing formatting standards to an existing codebase. Otherwise, it’s difficult to take advantage of QOL features like auto formatting in your editor, or other formatting tools which tend to operate on entire files. Then PRs end up being mixed with formatting changes, which adds friction to the review process.

bornfreddy 2y ago

Sure. Of course you can't commit to the main branch and your commit will never pass code review (which is a requirement for merging), let alone the automated tests in CI that apply formatting and fail if anything is not formatted as it should be. These safeguards save so much time that there should be no excuse for not having them.

alexvitkov 2y ago
Not wanting pipelines to fail because someone put an extra space after the line, or because someone's text editor didn't put a new line at EOF, or put a unicode BOM or whatever is a pretty good reason not to have this "safeguard".

jbaber 2y ago

I've had innocents' IDEs do this to them. Fortunately it results in pull request rejected, not commit to master.

nickysielicki 2y ago

Just to be clear, the argument for this has nothing to do with how the code looks and has everything to do with how you can swallow a pill, once, and in exchange you get clean rebases forever. You can hide the commit from blame consideration.

devnullbrain 2y ago
I've seen changes like this drag out over a year because the product had so many permutations that thoroughly testing any change was an exercise in futility. I've also seen changes like this fail to happen just due to a lack of cultural desire to make things happen. The first one is more forgivable - sometimes that's just the problem space. But neither of them are conducive to fulfilling working environments.