5 ms·

So now when you look at the annotated change history all you're going to see is a bunch of changes by the person that reformatted the code instead of the person

So now when you look at the annotated change history all you're going to see is a bunch of changes by the person that reformatted the code instead of the person that wrote it.

justinmchase 5y ago
You can see both of course. That's the beauty of history.
deleted 5y ago
[deleted]
tempay 5y ago
The `.git-blame-ignore-revs` file can be used to ignore that (and will be [1]). Unfortunatly GitHub doesn't support it but at least it's possible to have clients behave in a reasonable way. [1] https://github.com/django/django/pull/15387#issuecomment-1031848322 https://github.com/django/django/pull/15387#issuecomment-103...
- sciurus 5y ago
  For anyone looking for more explanation of this feature: https://michaelheap.com/git-ignore-rev/ https://michaelheap.com/git-ignore-rev/
- acidburnNSA 5y ago
  TIL about that git feature. Very nice.
- terr-dav 5y ago
  You can automate setup for developers using this simple script: https://github.com/ipython/ipython/pull/12091/files https://github.com/ipython/ipython/pull/12091/files And here’s a GitLab issue requesting support for blame-ignore: https://gitlab.com/gitlab-org/gitlab/-/issues/31423 https://gitlab.com/gitlab-org/gitlab/-/issues/31423 I don’t think there’s a corresponding GitHub request, but maybe if GitLab adds this feature GitHub will have some incentive to follow suit.
deleted 5y ago
[deleted]
Cthulhu_ 5y ago
There's workarounds that others have mentioned, but indeed, the unfortunate side-effect of deciding to apply a formatter is a 'formatting' commit, causing a lot of code churn and issues if naively using git blame. But, it's a "rip the plaster off" kinda thing, because it should ensure a lot less churn, inconsistent code style, or arguments and reviews about formatting after this is merged. It frees up a lot of headspace and distractions in code reviews. I don't know about you, but when I did code reviews I'd always end up zooming in on code style issues - ' vs ", things on newlines or no, JS objects with stringed keys, etc.
alecbz 5y ago
Uh so is your take "don't do broad refactors ever?" Beyond `.git-blame-ignore-revs` (which is neat and TIL), in GitHub's web viewer, if you find the line you're interested in and see that the most recent PR is a reformat, you click the "view blame prior to this change" button. I think most blame viewers do (or at least should) have a feature like this.

So now when you look at the annotated change history all you're going to see is a bunch of changes by the person that reformatted the code instead of the person that wrote it.

justinmchase 5y ago

You can see both of course. That's the beauty of history.

deleted 5y ago

[deleted]

tempay 5y ago

The `.git-blame-ignore-revs` file can be used to ignore that (and will be [1]). Unfortunatly GitHub doesn't support it but at least it's possible to have clients behave in a reasonable way. [1] https://github.com/django/django/pull/15387#issuecomment-1031848322 https://github.com/django/django/pull/15387#issuecomment-103...

sciurus 5y ago
For anyone looking for more explanation of this feature: https://michaelheap.com/git-ignore-rev/ https://michaelheap.com/git-ignore-rev/
acidburnNSA 5y ago
TIL about that git feature. Very nice.
terr-dav 5y ago
You can automate setup for developers using this simple script: https://github.com/ipython/ipython/pull/12091/files https://github.com/ipython/ipython/pull/12091/files And here’s a GitLab issue requesting support for blame-ignore: https://gitlab.com/gitlab-org/gitlab/-/issues/31423 https://gitlab.com/gitlab-org/gitlab/-/issues/31423 I don’t think there’s a corresponding GitHub request, but maybe if GitLab adds this feature GitHub will have some incentive to follow suit.

deleted 5y ago

[deleted]

Cthulhu_ 5y ago

There's workarounds that others have mentioned, but indeed, the unfortunate side-effect of deciding to apply a formatter is a 'formatting' commit, causing a lot of code churn and issues if naively using git blame. But, it's a "rip the plaster off" kinda thing, because it should ensure a lot less churn, inconsistent code style, or arguments and reviews about formatting after this is merged. It frees up a lot of headspace and distractions in code reviews. I don't know about you, but when I did code reviews I'd always end up zooming in on code style issues - ' vs ", things on newlines or no, JS objects with stringed keys, etc.

alecbz 5y ago

Uh so is your take "don't do broad refactors ever?" Beyond `.git-blame-ignore-revs` (which is neat and TIL), in GitHub's web viewer, if you find the line you're interested in and see that the most recent PR is a reformat, you click the "view blame prior to this change" button. I think most blame viewers do (or at least should) have a feature like this.