On 1/24/24 6:31 AM, Konrad Windszus wrote:
Ping, does anyone have any input on this? Would be much appreciated, Thanks, KonradOn 8. Jan 2024, at 19:16, Konrad Windszus <[email protected]> wrote: Hi, According to https://maven.apache.org/pom/maven/#the-format-profile the git commits created through applying the spotless formatting should be ignored via a .git-blame-ignore-revs file. This file is automatically evaluated by GitHub blame view. This doesn’t work well if the formatting also does some reordering of lines (most prominently through https://github.com/diffplug/spotless/tree/main/plugin-maven#sortpom). An example can be found in https://github.com/apache/sling-parent/blame/master/sling-parent/pom.xml#L270 which obviously shows a non-related commit in line 270 due to the ignored reordering commit (this is a different ASF projects but follows the same approach as Maven). The same may happen with reordering of lines in Java. I am wondering if there is a better approach, or we should rather not generally recommend to add those reformatting commits to .git-blame-ignore-revs. WDYT? Konrad
Konrad,I don't think I ever paid attention to this Maven workflow and tooling, deferring mostly to Checkstyle and pipeline tooling for Java.
Editing a file with SHAs adds friction: Who edits it? If it's not edited, what is the need/requirement to edit it after the fact? I see a separate file that needs manual action as process friction subject to all sorts of user issues. IMHO.
I'm aware that 'git blame' has "detect copy-move" switches, for example:
-C[<num>] In addition to -M, detect lines moved or copied from other files that were modified in the same commit. This is useful when you reorganize your program and move code around across files. When this option is given twice, the command additionally looks for copies from other files in the commit that creates the file. When this option is given three times, the command additionally looks for copies from other files in any commit. <num> is optional but it is the lower bound on the number of alphanumeric characters that Git must detect as moving/copying between files for it to associate those lines with the parent commit. And the default value is 40. If there are more than one -C options given, the <num> argument of the last -C will take effect.
Is it possible that this could be leveraged somehow? Certainly, pipelines could be scripted to use these features of Git.
-- Timothy Stone ============= Some call me ... Tim. Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D&D Find me on GitLab | GitHub | Linked In | MeWe | GnuPG
OpenPGP_signature.asc
Description: OpenPGP digital signature
