Add a .git-blame-ignore-revs file

[helen]

While we still use SVN and Trac as our sources of truth in core development, plenty of contributors use GitHub for their contribution workflows. GitHub is currently rolling out support for a Git-standard .git-blame-ignore-revs file in visual blame and ​it has been turned on for the WordPress org per the Gutenberg team's request. It would be nice to have a file with things like the classic "pinking shears" commits and others that are purely formatting changes. Examples would be [34534] and [42343].

This adds a .git-blame-ignore-revs file to exclude certain commits from visual blame on GitHub.com, which can also be used on the command line via git blame --ignore-revs-file .git-blame-ignore-revs.

Trac ticket: https://core.trac.wordpress.org/ticket/55422

[helen]

My initial PR is not a complete list of commits, though it does include all the commits I found for "pinking shears" with the exception of one that I noticed contained other changes. I would really love some help double checking these commits to make sure we're not including any that are anything besides whitespace/style fixes; it's better to be conservative to start. Would also like feedback / suggestions on the format of the file, particularly around the comments and how we label things to be able to maintain this file now and into the future.

Some "Code is Poetry" commits:
{{{bash
e4e1a54567dca12048e5344ab5b60a85e0d96743 # [4375]
e37aff4320b89bd94e21517f65d298f9f1fe6b37 # [45559]
}}}
and you already have this one under # PHPCS:
{{{bash
8f95800d52c1736d651ae6e259f90ad4a0db2c3f # [42343]
}}}

@costdev I personally see those two commits as more than purely stylistic; I don't believe anything would have been affected by those specifically but sometimes subtle things like that (especially that final falsey check) can cause side effects and I would want to see those in the history. Definitely open to the idea that being more liberal about leaving commits out of our default code archaeology is a good idea, but I think I'd need a lot of convincing :)

[costdev]

@helen I'll be going through the commits you have listed to check them as requested.

What do you think is the best way to make commit suggestions for ​PR 2433? Should we just leave a review comment on # PHPCS, for example, with the hashes and changesets so that they can be considered for the addition?

Aside from that, we have # Pinking shears and # PHPCS at the moment. This seems like a manageable limit for now given the number of "Coding Standards" commits to be checked.

I'm curious about everyone's thoughts on the approach and wonder when we should consider the PR for merging into Core. If the idea has support, should we commit the PR once commits have been reviewed and verified as stylistic-only changes, then proceed with additional PRs in a step-by-step approach, or?

[helen]

@costdev Thanks for taking a look! I think review comments and suggestions on the PR will work great.

I hadn't really thought a whole lot about the "MVP" point of this - I think your instinct is right, we can get these pinking shears and PHPCS ones verified and then commit this, and then work on adding coding standards ones in a second pass. However, before settling on that, does anybody have a sense of how many coding standards-type commits there are? A rough estimate based on keyword searches of commits is good enough.

[costdev]

There are 421 commits beginning with "Coding Standard" (case-insensitive).

• See ​here for the HASH # [REVISION] format.
  • The command I used is at the top of this file.
• See ​here for the HASH # [REVISION] # SUBJECT format.
  • This one should make it easier to spot which commits actually deal with PHPCS/WPCS configuration rather than stylistic changes.

Edit: I just remembered that markdown is a thing.

See ​here for the same commits but with a link to each one on the wordpress-develop GitHub repo.

I personally see those two commits as more than purely stylistic; I don't believe anything would have been affected by those specifically but sometimes subtle things like that (especially that final falsey check)

Yeah, e37aff4320b89bd94e21517f65d298f9f1fe6b37 broke something and was caught in the following commit. My code was not poetry.

[peterwilsoncc]

I think this is good to go in as an MVP.

The initial commit can go in as a See rather than a Fixes and further commits added once the act of committing gets additional eyes on the ticket.

I consider this tooling related so commits can go in during source freeze.

[helen]

Replying to costdev:

There are 421 commits beginning with "Coding Standard" (case-insensitive).

Whew. Let's leave that for separate commits then. Thanks for looking into that!

I left ​one more thought about whether to leave commits in but commented out for future us, once we resolve that then I agree on a commit with see. I'll dust off these SVN muscles again :)

I personally see those two commits as more than purely stylistic; I don't believe anything would have been affected by those specifically but sometimes subtle things like that (especially that final falsey check)

Yeah, ​e37aff4 broke something and was caught in the following commit. My code was not poetry.

@peterwilsoncc I feel both disappointed in myself that I didn't actually check on ​follow up commits and weirdly gratified that my worst instincts remain correct 😆

[peterwilsoncc]

I've answered the question inline on the PR.

Assigning to Helen for commit as an MVP.

[helen]

In 53007:

Build/Test Tools: First pass at a .git-blame-ignore-revs file.

This suppresses certain commits from Git blame views, notably in the GitHub UI as well as the command line. These commits are purely stylistic and excluding them from these views helps to reduce the noise when doing code archaeology.

Still to come: More coding standards commits as they are reviewed.

Props helen, costdev, peterwilsoncc.
See #55422

Committed in 921d2805a0ebaf4db9f75ea9f5af46e48d6f68ac

[helen]

Noticed [12733] / 8ef8b7bad509520896877fdac4882192d746d51a while checking out the ​much improved visual blame, just leaving a note here for further commits :)

This is continued work on adding revisions to .git-blame-ignore-revs to be ignored in blame views. Let's use comments and suggestions to work through adding new ones collaboratively.

Trac ticket: https://core.trac.wordpress.org/ticket/55422

[hellofromTonya]

6.0 RC1 is tomorrow. Though build/test tools can be committed at any time, moving remaining work to 6.1 cycle to clear the 6.0 milestone for RC.

[peterwilsoncc]

I've moved this back to the 6.0 milestone so r53007 doesn't get detached from the milestone in which it was committed.

A follow up ticket can be created for continued work on this in 6.1, similar to the docs, coding standards and tests tickets.