Make WordPress Core

Opened 2 years ago

Last modified 9 months ago

#56029 new defect (bug)

.git-blame-ignore-revs causes other revisions to be ignored

Reported by: johnbillion's profile johnbillion Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 6.0
Component: Build/Test Tools Keywords: good-first-bug needs-patch
Focuses: Cc:

Description

Previously: #55422

It appears that the .git-blame-ignore-revs file is causing revisions other than those listed to be ignored when using the "View blame prior to this change" button on GitHub. This might be a bug in GitHub or it might be a side effect of how Git ignores revisions and produces an inability to keep track of changes to a line across major changes.

Steps to reproduce:

The actual previous revision was the Code is Poetry commit ([42343]) which is listed in .git-blame-ignore-revs. Prior to this commit, there was 97fcbef ([29221]) which is an actual functional change which is being ignored.

Removing the code formatting and pinking commits from the blame views is useful, but preventing history from being accurately traced back is a problem.

Options:

  • Ask GitHub to investigate or advise
  • Remove the .git-blame-ignore-revs file for now

cc @helen

Attachments (1)

Screenshot 2023-10-17 at 11.01.56 AM.png (409.5 KB) - added by desrosj 9 months ago.

Download all attachments as: .zip

Change History (4)

#1 @costdev
2 years ago

Confirmed as also occurring in VS Code with the GitLens extension and the following in settings.json:

{
    "gitlens.advanced.blame.customArguments": ["--ignore-revs-file", ".git-blame-ignore-revs"]
}

#2 @costdev
2 years ago

Using Git, adding the ignore-revs file with this command:

git config --local blame.ignoreRevsFile .git-blame-ignore-revs

Produces this result:

git blame -L946,946 src/wp-includes/pluggable.php

# Output (Incorrect)
78a2c0f7815 wp-includes/pluggable.php (Ryan Boren 2008-08-21 00:08:25 +0000 946) list( $username, $expiration, $token, $hmac ) = $cookie_elements;

Removing the ignore-revs file with this command:

git config --local blame.ignoreRevsFile ""

And instead passing the -w flag produces this result:

git blame -w -L946,946 src/wp-includes/pluggable.php

# Output (Correct)
97fcbef707e (Andrew Nacin 2014-07-18 09:12:05 +0000 946) list( $username, $expiration, $token, $hmac ) = $cookie_elements;

This does indeed point to the behaviour of the ignore-revs file.

#3 @desrosj
9 months ago

  • Keywords good-first-bug needs-patch added

The line of the code in the original description has changed. Here's a link to the same blame view but pinned to the most recent commit at the time of publishing this comment: https://github.com/WordPress/wordpress-develop/blame/7856fcbd8cd24854dae0bc0c1a718860411b9065/src/wp-includes/pluggable.php#L948.

I'm not sure if it's significant, but when viewing the file in GitHub all lines are red. But it's not clear if this is indicating an error, or something else.

I guess it's possible that having an inline comment at the end of the line is causing problems with the ability to properly parse/apply the file. The documentation on GitHub does suggest a different format:

# .git-blame-ignore-revs
# Removed semi-colons from the entire codebase
a8940f7fbddf7fad9d7d50014d4e8d46baf30592
# Converted all JavaScript to TypeScript
69d029cec8337c616552756310748c4a507bd75a

It could also be the presence of the [] causing issues.

I looked at the file for a few other projects, and they don't seem to have this red highlighting. For one example, see the .git-blame-ignore-revs file for the Rust project.

I think adjusting the format to follow the recommendation in the documentation is a good step to take. Having the short title for each commit message before the SHA helps make the file more human-readable, and we could include full URLs to the Core Trac changeset pages instead of the [#####] style comment, which in the context of GIT/GitHub means nothing.

Note: See TracTickets for help on using tickets.