[wp-trac] [WordPress Trac] #56029: .git-blame-ignore-revs causes other revisions to be ignored
WordPress Trac
noreply at wordpress.org
Tue Oct 17 15:09:32 UTC 2023
#56029: .git-blame-ignore-revs causes other revisions to be ignored
----------------------------------------+------------------------------
Reporter: johnbillion | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Build/Test Tools | Version: 6.0
Severity: normal | Resolution:
Keywords: good-first-bug needs-patch | Focuses:
----------------------------------------+------------------------------
Changes (by desrosj):
* keywords: => good-first-bug needs-patch
Comment:
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
[https://docs.github.com/en/repositories/working-with-files/using-
files/viewing-a-file#ignore-commits-in-the-blame-view 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`
[https://github.com/rust-
lang/rust/blob/616e37919c87f34d3af57ab7457186a4e0cd62ef/.git-blame-ignore-
revs#L4 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.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/56029#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list