Top-level .clang-tidy options and VariableName suggestion on CodingStandards

Hi all,

I created a .clang-tidy patch ⚙ D108265 .clang-tidy: Push variable related readability-identifier-naming options down to projects to push
the variable naming related options from
top-level .clang-tidy down to the projects actually using the style
(llvm/, clang-tools-extra/).

The rationale is: uppercase VariableName doesn't really reflect the
reality for many projects and (in my view) is a bad
suggestion for new projects. My summary about the reality:

* Use VariableName and have readability-identifier-naming check: llvm,
clang-tools-extra, parallel-libs, polly
* Use VariableName but disable readability-identifier-naming: clang
* Use lowercase variable names and disable
readability-identifier-naming: (mostly lowercase) compiler-rt, flang,
lldb
* Use lowercase variable names and enable
readability-identifier-naming: libc, libclc, libcxx, libcxxabi,
libunwind, lld, mlir, openmp, pstl

(I noticed the issue because some Phabricator bot wanted me to use
VariableName for a libunwind patch of mine.
The request looked unreasonable to me. I could add
libunwind/.clang-tidy, but I figured out the top-level .clang-tidy
problem.)

From my vague memory about previous discussion on variable names, most

people agree that VariableName was a mistake and new projects do not
necessarily need to follow.

However, one feedback is that
https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly
says

Variable names should be nouns (as they represent state). The name should be camel case, and start with an uppercase letter (e.g. Leader or Boats).

so the top-level .clang-tidy should keep the `VariableName` suggestion
and should apply to new top-level projects.

Request

Hi all,

I created a .clang-tidy patch https://reviews.llvm.org/D108265 to push
the variable naming related options from
top-level .clang-tidy down to the projects actually using the style
(llvm/, clang-tools-extra/).

The rationale is: uppercase VariableName doesn’t really reflect the
reality for many projects and (in my view) is a bad
suggestion for new projects. My summary about the reality:

  • Use VariableName and have readability-identifier-naming check: llvm,
    clang-tools-extra, parallel-libs, polly
  • Use VariableName but disable readability-identifier-naming: clang
  • Use lowercase variable names and disable
    readability-identifier-naming: (mostly lowercase) compiler-rt, flang,
    lldb
  • Use lowercase variable names and enable
    readability-identifier-naming: libc, libclc, libcxx, libcxxabi,
    libunwind, lld, mlir, openmp, pstl

(I noticed the issue because some Phabricator bot wanted me to use
VariableName for a libunwind patch of mine.
The request looked unreasonable to me. I could add
libunwind/.clang-tidy, but I figured out the top-level .clang-tidy
problem.)

From my vague memory about previous discussion on variable names, most
people agree that VariableName was a mistake and new projects do not
necessarily need to follow.

Might be worth going back over those discussions and summarizing/linking to supporting archives, etc, so we don’t rehash the whole conversation again here? (& cc’ing interested parties so they don’t have to stumble across this thread or miss it by accident)

However, one feedback is that
https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly
says

Variable names should be nouns (as they represent state). The name should be camel case, and start with an uppercase letter (e.g. Leader or Boats).

so the top-level .clang-tidy should keep the VariableName suggestion
and should apply to new top-level projects.

Request

I would like to get feedback on the following two points:

  1. Should we proceed with the .clang-tidy change
    https://reviews.llvm.org/D108265 ?
  2. Should the VariableName wording on CodingStandards.html be
    clarified/relaxed? llvm, clang, and clang-tools-extra can keep using
    it but lowercase names should also be allowed.

Further thought: I don’t think (1) should proceed as-is no matter the decision on (2). We should have an LLVM umbrella naming convention (I don’t think the number of projects that use one or the other should be a vote in favor or against - LLVM Core is still the core of the umbrella project and has more weight here than other subprojects (not the only thing that matters, but part of it), removing any naming convention I think would be unhelpful.

& I don’t think (2) should be “use either of these naming conventions” it should be “this is the naming convention” perhaps with a note that LLVM Core (& some other places, such as clang-tools-extra) uses a different one for historical reasons, for instance.

Hi all,

I created a .clang-tidy patch ⚙ D108265 .clang-tidy: Push variable related readability-identifier-naming options down to projects to push
the variable naming related options from
top-level .clang-tidy down to the projects actually using the style
(llvm/, clang-tools-extra/).

The rationale is: uppercase VariableName doesn't really reflect the
reality for many projects and (in my view) is a bad
suggestion for new projects. My summary about the reality:

* Use VariableName and have readability-identifier-naming check: llvm,
clang-tools-extra, parallel-libs, polly
* Use VariableName but disable readability-identifier-naming: clang
* Use lowercase variable names and disable
readability-identifier-naming: (mostly lowercase) compiler-rt, flang,
lldb
* Use lowercase variable names and enable
readability-identifier-naming: libc, libclc, libcxx, libcxxabi,
libunwind, lld, mlir, openmp, pstl

(I noticed the issue because some Phabricator bot wanted me to use
VariableName for a libunwind patch of mine.
The request looked unreasonable to me. I could add
libunwind/.clang-tidy, but I figured out the top-level .clang-tidy
problem.)

From my vague memory about previous discussion on variable names, most
people agree that VariableName was a mistake and new projects do not
necessarily need to follow.

Might be worth going back over those discussions and summarizing/linking to supporting archives, etc, so we don't rehash the whole conversation again here? (& cc'ing interested parties so they don't have to stumble across this thread or miss it by accident)

Variable Names Plan — LLVM 16.0.0git documentation has a
summary of the 2019 discussion.

"There is some agreement that the current rule is broken
[LattnerAgree] [ArsenaultAgree] [RobinsonAgree] and that acronyms are
an obstacle to reading new code [MalyutinDistinguish] [CarruthAcronym]
[PicusAcronym]. There are some opposing views [ParzyszekAcronym2]
[RicciAcronyms]."

Perhaps "some" can be converted to "majority" or "full".
Everyone thinks VariableName was a mistake.
(The "opposing views" were about whether it was worthwhile to switch
to a variant of lowerCase/lower_case for existing code (mostly llvm/,
clang/, clang-tools-extra/).)

However, one feedback is that
LLVM Coding Standards — LLVM 16.0.0git documentation
says

> Variable names should be nouns (as they represent state). The name should be camel case, and start with an uppercase letter (e.g. Leader or Boats).

so the top-level .clang-tidy should keep the `VariableName` suggestion
and should apply to new top-level projects.

Request

I would like to get feedback on the following two points:

1. Should we proceed with the .clang-tidy change
⚙ D108265 .clang-tidy: Push variable related readability-identifier-naming options down to projects ?
2. Should the VariableName wording on CodingStandards.html be
clarified/relaxed? llvm, clang, and clang-tools-extra can keep using
it but lowercase names should also be allowed.

Further thought: I don't think (1) should proceed as-is no matter the decision on (2). We should have an LLVM umbrella naming convention (I don't think the number of projects that use one or the other should be a vote in favor or against - LLVM Core is still the core of the umbrella project and has more weight here than other subprojects (not the only thing that matters, but part of it), removing any naming convention I think would be unhelpful.
& I don't think (2) should be "use either of these naming conventions" it should be "this is the naming convention" perhaps with a note that LLVM Core (& some other places, such as clang-tools-extra) uses a different one for historical reasons, for instance.

There were debates about whether camelCase/snake_case should be used
for variable names,
Personally I am fine with either one but slightly prefer snake_case.
New projects using either form will be fine to me.

For (1), I have some doubt whether there will be an LLVM umbrella
naming convention for variable names,
but I **don't** consider the lack of convergence (to either camelCase
or snake_case) an argument for keeping VariableName in the in the
top-level .clang-tidy .
Actually I strongly oppose to keeping VariableName in the top-level
.clang-tidy, or new projects adopting VariableName.

Hi all,

I created a .clang-tidy patch https://reviews.llvm.org/D108265 to push
the variable naming related options from
top-level .clang-tidy down to the projects actually using the style
(llvm/, clang-tools-extra/).

The rationale is: uppercase VariableName doesn’t really reflect the
reality for many projects and (in my view) is a bad
suggestion for new projects. My summary about the reality:

  • Use VariableName and have readability-identifier-naming check: llvm,
    clang-tools-extra, parallel-libs, polly
  • Use VariableName but disable readability-identifier-naming: clang
  • Use lowercase variable names and disable
    readability-identifier-naming: (mostly lowercase) compiler-rt, flang,
    lldb
  • Use lowercase variable names and enable
    readability-identifier-naming: libc, libclc, libcxx, libcxxabi,
    libunwind, lld, mlir, openmp, pstl

(I noticed the issue because some Phabricator bot wanted me to use
VariableName for a libunwind patch of mine.
The request looked unreasonable to me. I could add
libunwind/.clang-tidy, but I figured out the top-level .clang-tidy
problem.)

From my vague memory about previous discussion on variable names, most
people agree that VariableName was a mistake and new projects do not
necessarily need to follow.

Might be worth going back over those discussions and summarizing/linking to supporting archives, etc, so we don’t rehash the whole conversation again here? (& cc’ing interested parties so they don’t have to stumble across this thread or miss it by accident)

https://llvm.org/docs/Proposals/VariableNames.html#introduction has a
summary of the 2019 discussion.

“There is some agreement that the current rule is broken
[LattnerAgree] [ArsenaultAgree] [RobinsonAgree] and that acronyms are
an obstacle to reading new code [MalyutinDistinguish] [CarruthAcronym]
[PicusAcronym]. There are some opposing views [ParzyszekAcronym2]
[RicciAcronyms].”

Perhaps “some” can be converted to “majority” or “full”.
Everyone thinks VariableName was a mistake.

“everyone” might be too strong a statement - there’s no real way to determine that, effectively.

(The “opposing views” were about whether it was worthwhile to switch
to a variant of lowerCase/lower_case for existing code (mostly llvm/,
clang/, clang-tools-extra/).)

Personally, I don’t find one naming convention over another (of the ones being considered) to be sufficiently different in usability to justify making any changes. But partly to justify making lots of changes to LLVM core, or, in the absence of such changes, to create more divergence between that code and other subprojects (because most folks will work on LLVM core + some subprojects, so consistency with LLVM core is pretty important).

However, one feedback is that
https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly
says

Variable names should be nouns (as they represent state). The name should be camel case, and start with an uppercase letter (e.g. Leader or Boats).

so the top-level .clang-tidy should keep the VariableName suggestion
and should apply to new top-level projects.

Request

I would like to get feedback on the following two points:

  1. Should we proceed with the .clang-tidy change
    https://reviews.llvm.org/D108265 ?
  2. Should the VariableName wording on CodingStandards.html be
    clarified/relaxed? llvm, clang, and clang-tools-extra can keep using
    it but lowercase names should also be allowed.

Further thought: I don’t think (1) should proceed as-is no matter the decision on (2). We should have an LLVM umbrella naming convention (I don’t think the number of projects that use one or the other should be a vote in favor or against - LLVM Core is still the core of the umbrella project and has more weight here than other subprojects (not the only thing that matters, but part of it), removing any naming convention I think would be unhelpful.
& I don’t think (2) should be “use either of these naming conventions” it should be “this is the naming convention” perhaps with a note that LLVM Core (& some other places, such as clang-tools-extra) uses a different one for historical reasons, for instance.

There were debates about whether camelCase/snake_case should be used
for variable names,
Personally I am fine with either one but slightly prefer snake_case.
New projects using either form will be fine to me.

For (1), I have some doubt whether there will be an LLVM umbrella
naming convention for variable names,
but I don’t consider the lack of convergence (to either camelCase
or snake_case) an argument for keeping VariableName in the in the
top-level .clang-tidy .
Actually I strongly oppose to keeping VariableName in the top-level
.clang-tidy, or new projects adopting VariableName.

It’s pretty important to me that we don’t make it easier to create more divergence in naming conventions - creating another project that diverges from LLVM’s naming conventions/creates more naming inconsistency seems like a loss to me. So until there’s some buy-in for a desired future direction, I think new projects should adhere to the existing convention.

I don’t think that future direction must include a way to cleanup LLVM - as Chris Lattner said, maybe it is something like “Even if the community does not have the appetite to do a huge scale renaming of all the things in LLVM, it would be interesting to carve out an exception for new code being written, refactored, or potentially for use in new subprojects.” - though I think that’s a choice we should all make together (doesn’t require it to be unanimous) and carefully. That does produce the inconsistent-with-LLVM-core issue I’m concerned about, but maybe with a path forward to consistency. Might be worth talking about whether people would be comfortable with more active cleanup - not necessarily one huge renaming, but be willing to accept patches that rename things without necessarily being pieces of code being actively refactored for other reasons. That’d help alleviate the “now we’re going to have N different conventions based on when a given subproject was introduced”, which increases friction when moving between subprojects (as zturner pointed out in some of the discussion/code review of style changes proposed previously). - Dave

Hi,

Just a couple cents from a relative newcomer to LLVM, please take them
with their appropriate worth :wink:

It's pretty important to me that we don't make it easier to create
more divergence in naming conventions - creating another project that
diverges from LLVM's naming conventions/creates more naming
inconsistency seems like a loss to me. So until there's some buy-in
for a desired future direction, I think new projects should adhere to
the existing convention.

FWIW I found when switching between lld and llvm to be jarring -- I had
to know that there were two coding conventions, and that one was
documented and one was not. It wasted a bit of reviewer time pointing
out these issues (though of course the tools helped).

I don't think that future direction must include a way to cleanup LLVM
- as Chris Lattner said, maybe it is something like "Even if the
community does not have the appetite to do a huge scale renaming of
all the things in LLVM, it would be interesting to carve out an
exception for new code being written, refactored, or potentially for
use in new subprojects." - though I think that's a choice we should
all make together (doesn't require it to be unanimous) and
carefully. That does produce the inconsistent-with-LLVM-core issue I'm
concerned about, but maybe with a path forward to consistency. Might
be worth talking about whether people would be comfortable with more
active cleanup - not necessarily one huge renaming, but be willing to
accept patches that rename things without necessarily being pieces of
code being actively refactored for other reasons. That'd help
alleviate the "now we're going to have N different conventions based
on when a given subproject was introduced", which increases friction
when moving between subprojects (as zturner pointed out in some of the
discussion/code review of style changes proposed previously). - Dave

Here again I found problems when switching to clang -- you end up with
different naming conventions per file (what is the convention for
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/ConstantEmitter.h
? When making a patch, which convention to use?) and sometimes even
within a file (consider
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.h#L4819-L4831
vs
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.h#L1484-L1491).
So when making a patch I have to know not only the coding convention but
also the direction that things are supposed to be going, and there does
not appear to be project-wide consensus on that.

Also just FWIW, when I was working on Firefox they changed coding
conventions but did so with a big bang switch. I found it much easier
to navigate -- the situation was at all times clear to me.

From my limited perspective It Would Be Good™ if llvm would end up in a

situation where the coding conventions were always enforced -- the
situation in clang is perhaps the least desirable one. And bonus if it
is the same convention across the project :slight_smile:

Regards,

Andy

Hi,

Just a couple cents from a relative newcomer to LLVM, please take them
with their appropriate worth :wink:

It’s pretty important to me that we don’t make it easier to create
more divergence in naming conventions - creating another project that
diverges from LLVM’s naming conventions/creates more naming
inconsistency seems like a loss to me. So until there’s some buy-in
for a desired future direction, I think new projects should adhere to
the existing convention.

FWIW I found when switching between lld and llvm to be jarring – I had
to know that there were two coding conventions, and that one was
documented and one was not. It wasted a bit of reviewer time pointing
out these issues (though of course the tools helped).

I don’t think that future direction must include a way to cleanup LLVM

  • as Chris Lattner said, maybe it is something like “Even if the
    community does not have the appetite to do a huge scale renaming of
    all the things in LLVM, it would be interesting to carve out an
    exception for new code being written, refactored, or potentially for
    use in new subprojects.” - though I think that’s a choice we should
    all make together (doesn’t require it to be unanimous) and
    carefully. That does produce the inconsistent-with-LLVM-core issue I’m
    concerned about, but maybe with a path forward to consistency. Might
    be worth talking about whether people would be comfortable with more
    active cleanup - not necessarily one huge renaming, but be willing to
    accept patches that rename things without necessarily being pieces of
    code being actively refactored for other reasons. That’d help
    alleviate the “now we’re going to have N different conventions based
    on when a given subproject was introduced”, which increases friction
    when moving between subprojects (as zturner pointed out in some of the
    discussion/code review of style changes proposed previously). - Dave

Here again I found problems when switching to clang – you end up with
different naming conventions per file (what is the convention for
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/ConstantEmitter.h
? When making a patch, which convention to use?) and sometimes even
within a file (consider
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.h#L4819-L4831
vs
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.h#L1484-L1491).
So when making a patch I have to know not only the coding convention but
also the direction that things are supposed to be going, and there does
not appear to be project-wide consensus on that.

Also just FWIW, when I was working on Firefox they changed coding
conventions but did so with a big bang switch. I found it much easier
to navigate – the situation was at all times clear to me.

Any idea what, if anything, they did to address issues of revision history navigation, helping people update their outstanding patches over the transition, etc?

First of all, thank you for pushing on this topic. I would agree that UpperCamelCase naming style was a mistake.

[snip]

Further thought: I don’t think (1) should proceed as-is no matter the decision on (2). We should have an LLVM umbrella naming convention (I don’t think the number of projects that use one or the other should be a vote in favor or against - LLVM Core is still the core of the umbrella project and has more weight here than other subprojects (not the only thing that matters, but part of it), removing any naming convention I think would be unhelpful.

& I don’t think (2) should be “use either of these naming conventions” it should be “this is the naming convention” perhaps with a note that LLVM Core (& some other places, such as clang-tools-extra) uses a different one for historical reasons, for instance.

That sounds fair.

There were debates about whether camelCase/snake_case should be used
for variable names,
Personally I am fine with either one but slightly prefer snake_case.
New projects using either form will be fine to me.

For (1), I have some doubt whether there will be an LLVM umbrella
naming convention for variable names,
but I don’t consider the lack of convergence (to either camelCase
or snake_case) an argument for keeping VariableName in the in the
top-level .clang-tidy .
Actually I strongly oppose to keeping VariableName in the top-level
.clang-tidy, or new projects adopting VariableName.

It’s pretty important to me that we don’t make it easier to create more divergence in naming conventions - creating another project that diverges from LLVM’s naming conventions/creates more naming inconsistency seems like a loss to me. So until there’s some buy-in for a desired future direction, I think new projects should adhere to the existing convention.

I don’t think that future direction must include a way to cleanup LLVM - as Chris Lattner said, maybe it is something like “Even if the community does not have the appetite to do a huge scale renaming of all the things in LLVM, it would be interesting to carve out an exception for new code being written, refactored, or potentially for use in new subprojects.” - though I think that’s a choice we should all make together (doesn’t require it to be unanimous) and carefully. That does produce the inconsistent-with-LLVM-core issue I’m concerned about, but maybe with a path forward to consistency.

Might be worth talking about whether people would be comfortable with more active cleanup - not necessarily one huge renaming, but be willing to accept patches that rename things without necessarily being pieces of code being actively refactored for other reasons. That’d help alleviate the “now we’re going to have N different conventions based on when a given subproject was introduced”, which increases friction when moving between subprojects (as zturner pointed out in some of the discussion/code review of style changes proposed previously).

My view is that changes for purely stylistic reasons hurt much more than switching between projects with different variable naming styles.

LLVM de facto very much has a distributed development model. Even teams that work close to upstream often have their own branches where changes are developed before they are ready for Phabricator. Style changes have a tendency to introduce totally pointless merge failures. Anybody who is proposing purely stylistic changes is usually proposing creating a lot of busywork for a lot of people. It*s just not worth it.

(Sometimes, stylistic cleanups are truly confined to a single file. In that case, they may be fine, especially when the file doesn’t change very much in the first place. As soon as you’re changing names in header files, though, you’re very likely going to cause problems.)

Mandating a move away from UpperCamelCase for new code, and allowing (or perhaps suggesting) renames away from UpperCamelCase for code that is being refactored anyway, is the way to go in my opinion.

Cheers,
Nicolai

First of all, thank you for pushing on this topic. I would agree that UpperCamelCase naming style was a mistake.

[snip]

Further thought: I don’t think (1) should proceed as-is no matter the decision on (2). We should have an LLVM umbrella naming convention (I don’t think the number of projects that use one or the other should be a vote in favor or against - LLVM Core is still the core of the umbrella project and has more weight here than other subprojects (not the only thing that matters, but part of it), removing any naming convention I think would be unhelpful.

& I don’t think (2) should be “use either of these naming conventions” it should be “this is the naming convention” perhaps with a note that LLVM Core (& some other places, such as clang-tools-extra) uses a different one for historical reasons, for instance.

That sounds fair.

There were debates about whether camelCase/snake_case should be used
for variable names,
Personally I am fine with either one but slightly prefer snake_case.
New projects using either form will be fine to me.

For (1), I have some doubt whether there will be an LLVM umbrella
naming convention for variable names,
but I don’t consider the lack of convergence (to either camelCase
or snake_case) an argument for keeping VariableName in the in the
top-level .clang-tidy .
Actually I strongly oppose to keeping VariableName in the top-level
.clang-tidy, or new projects adopting VariableName.

It’s pretty important to me that we don’t make it easier to create more divergence in naming conventions - creating another project that diverges from LLVM’s naming conventions/creates more naming inconsistency seems like a loss to me. So until there’s some buy-in for a desired future direction, I think new projects should adhere to the existing convention.

I don’t think that future direction must include a way to cleanup LLVM - as Chris Lattner said, maybe it is something like “Even if the community does not have the appetite to do a huge scale renaming of all the things in LLVM, it would be interesting to carve out an exception for new code being written, refactored, or potentially for use in new subprojects.” - though I think that’s a choice we should all make together (doesn’t require it to be unanimous) and carefully. That does produce the inconsistent-with-LLVM-core issue I’m concerned about, but maybe with a path forward to consistency.

Might be worth talking about whether people would be comfortable with more active cleanup - not necessarily one huge renaming, but be willing to accept patches that rename things without necessarily being pieces of code being actively refactored for other reasons. That’d help alleviate the “now we’re going to have N different conventions based on when a given subproject was introduced”, which increases friction when moving between subprojects (as zturner pointed out in some of the discussion/code review of style changes proposed previously).

My view is that changes for purely stylistic reasons hurt much more than switching between projects with different variable naming styles.

LLVM de facto very much has a distributed development model. Even teams that work close to upstream often have their own branches where changes are developed before they are ready for Phabricator. Style changes have a tendency to introduce totally pointless merge failures.

I don’t think they’re totally pointless or busywork (there’s value in the consistency, but there’s significant costs to get there) - but they are real costs to consider, to be sure.

Anybody who is proposing purely stylistic changes is usually proposing creating a lot of busywork for a lot of people. It*s just not worth it.

Part of my hope would be that if we do wider scale cleanups we’ll do so with tooling to make it easier for out of tree branches and patches to update to match the in-tree changes. (& one significant period of pain, rather than refactoring a file at a time from time to time)

Also having different naming per file (or worse) is sort of where clang is, and has been an ongoing source of difficulty - so I think it’d be good to avoid that. I’d be amenable to a per-directory naming convention migration - using .clang-tidy files to document the format for a given directory/make it easy for developers to know what convention to use in a given location. But I suspect it’d be better overall to adopt a more “all or nothing” approach (keep one convention per subproject at least - accepting that that means LLVM Core would never change - which I think would be unfortunate).

Greets,

Also just FWIW, when I was working on Firefox they changed coding
conventions but did so with a big bang switch. I found it much easier
to navigate -- the situation was at all times clear to me.

Any idea what, if anything, they did to address issues of revision history navigation, helping people update their outstanding patches over the transition, etc?

Here is the thread with all the information:

  https://groups.google.com/g/mozilla.dev.platform/c/VCLB1Lz4yXc/m/dNoNVzmlCQAJ

To answer more directly, with info from that thread:

  - The commit in which reformatting is done is marked as "skip-blame" in
    their VCS (mercurial). Git has a similar facility now:
    Ignoring bulk change commits with git blame - Moxio

    As noted in the thread, "git hyper-blame" from Google's depot_tools
    is another option:
    https://groups.google.com/g/mozilla.dev.platform/c/VCLB1Lz4yXc/m/WAk50u_SCQAJ.
    Probably not needed though given that git can do it itself at this
    point.

  - For outstanding patches, they developed a mercurial extension to fix
    local changes in a way I don't fully understand:
    hg-formatsource · PyPI.

    For Firefox dev I use the git mirror with a git/hg transition tool
    -- I mostly don't have to think about hg. So IIRC for my
    outstanding patches I did an interactive rebase, added an additional
    base commit before any of my patches that ran the reformatter on the
    files I touched, then for each commit in my stack, I did a "git
    reset --soft" of the tree to the original pre-rebase commit, then
    ran the reformatter on the union of the files changed in the patch
    set. The result was a patch series that could then rebase past the
    reformatting commit without issues, dropping the newly added base
    commit.

    I could be misremembering; I don't think I had huge patches in
    flight at that point and I do understand how it could be gnarly.

Cheers,

Andy