3

I have changed some eslint rules for our team. One member of the team raised a PR that had ran prettier --fix on the entire codebase. We currently have lint-staged so only files that have been actively changed will get these updated eslint/prettier rules applied to them.

I wondered, is it possible to run prettier/eslint against the entire codebase and keep the author that was on the line before we applied these new rules. I am happy to lose the hash etc.

tkruse
  • 10,222
  • 7
  • 53
  • 80
Jamie Hutber
  • 26,790
  • 46
  • 179
  • 291
  • 2
    If you change the commit message or any file in the commit, then you are rewriting that commit. There is no way around this. – Tim Biegeleisen Apr 12 '19 at 11:20
  • I thought as much, I'd be happy to change the hash, I'd just like to keep the author. – Jamie Hutber Apr 12 '19 at 11:21
  • @JamieHutber If you don't mind changing the hash, you can change (and keep, too) whatever you like. – Acorn Apr 12 '19 at 11:21
  • :) So I could change the code ie `"` to `'` and leave the author before I edited it? – Jamie Hutber Apr 12 '19 at 11:27
  • 2
    Not per line, no. The whole commit will get the same author. So if the prettifier changes several lines, and those lines were made by different authors, you would need to make several different commits. Maybe you could go through the history, prettify each commit individually and [fixup the commit](https://blog.filippo.io/git-fixup-amending-an-older-commit/); but I have no idea if that is even feasible - and if it breaks, you have a big fat mess. – Amadan Apr 12 '19 at 11:32
  • Ye, I don't think this would be. Anything that would take more than 5mins would not be something I would entertain. I am happy just using `lint-staged` to manage this. – Jamie Hutber Apr 12 '19 at 11:38
  • 1
    It sounds like you want to keep the original author of each line, regardless of which commit it occurs in. I'm sure you could work out a way to automate this, however you would likely re-write a significant (if not all) of your git history. Are you sure this is something you need to do? Just for reference, when you rebase a commit, the original author and author date is retained, you can use `git log --format=fuller` to see who modified the commit. – Adam Nierzad Apr 12 '19 at 12:25
  • https://softwareengineering.stackexchange.com/questions/390160/how-to-manage-a-global-source-code-style-change/390210#390210 tl;dr balme woudl never show the real author straight away. Instead, educate users to keep blaming until they find the real commit – max630 Apr 14 '19 at 16:39
  • Possible duplicate of [Git commit that doesn't override original authors in git blame](https://stackoverflow.com/questions/3945382/git-commit-that-doesnt-override-original-authors-in-git-blame), also https://stackoverflow.com/questions/4112410 – tkruse Apr 17 '19 at 02:50

1 Answers1

0

See the related questions:

and consider git blame -w -M to avoid seeing authors for whitespace only changes / moved lines, which would cover a lot of eslint-based changes, I guess.

tkruse
  • 10,222
  • 7
  • 53
  • 80