[llvm-dev] Top-level .clang-tidy options and VariableName suggestion on CodingStandards

[Andy Wingo via llvm-dev]

Greets,

On Fri 20 Aug 2021 19:18, David Blaikie <dblaikie at gmail.com> writes:

> On Fri, Aug 20, 2021 at 12:03 AM Andy Wingo <wingo at igalia.com> wrote:
>
>  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:
    https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame

    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:
    https://pypi.org/project/hg-formatsource/.

    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