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

[johnbillion]

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:

• ​Visit the blame view for wp-includes/pluggable.php on GitHub
• One line 946 you'll see:

  list( $username, $expiration, $token, $hmac ) = $cookie_elements;
  

• Observe the previous revision for this line is listed as ​78a2c0f which is [8696] from the year 2008

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

[costdev]

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"]
}

[costdev]

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.

[desrosj]

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.

[rtiodev]

Replying to rtiodev:

removing good-first-bug as this task doesn't seem to fit this purpose.