Le dim. 16 oct. 2022 à 10:11, Hervé Boutemy <herve.bout...@free.fr> a écrit :
> key prerequisite is to make sure we don't screw history with the big > reformat > commits: I absolutely need to keep git blame provide useful feedback. > Right, good point. > it seems git blame --ignore-revs in Git 2.23 does what we need: > https://michaelheap.com/git-ignore-rev/ I did not know that feature, it seems to work quite well for us ! Does anybody have experience with this and its support in different > extended > tools, like GitHub > https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/ > or IDEs? > > I'd prefer we test on one non-sensitive small Git repo before doing such a > change in the important ones > I did it on my maven-resolver fork, just adding the git blame [1] and the output [2] looks quite nice and ignores the previous reformat commit. Guillaume [1] https://github.com/gnodet/maven-resolver/commit/3d6ea3b53cc3ace7ae8206a0095f3b30d9130efa [2] https://github.com/gnodet/maven-resolver/blame/reformat/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositorySystem.java Regards, > > Hervé > > Le mercredi 12 octobre 2022, 18:23:38 CEST Guillaume Nodet a écrit : > > Related to the discussion about automatically formatting and sorting > > imports, I think it would be nice, given the big reformat commits if > those > > PRs are to be merged, to eventually discuss some changes to those code > > style. In particular, I found out that the code is very sparse and my > > screen is more wide than height, which means I can usually only see 30-40 > > lines of code, where sometime half of them do not really carry any > semantic > > (open braces, or things like close brace + else + open brace on 3 lines). > > This makes me scroll a lot even on quite small methods to be able to read > > the full code, and that's a pain imho. > > So I'd like to propose the following changes that would make maven code > > more readable imho (and also closer to the usual java coding style) : > > * move open braces to the end of the previous line on all places > > * allow the else keyword to be directly following a closing brace to > > allow "} else {" to be on the same line > > * eventually relax a bit the checkstyle line length as described in > > https://github.com/gnodet/maven-shared-resources/pull/2. This has not > much > > effect, as the formatter will automatically format the lines and wrap > them > > at 120. However, in certain cases, the formatter can find in difficult to > > wrap the line (for example with a variable declaration and cast with a > > fully qualified name) and there is either a need to manually force the > wrap > > (using an end of line comment for example) or disabling the check with a > > @SuppressWarning( "checkstyle:LineLength" ) annotation. This change only > > removes the checks so that in those rare cases, the formatter can be left > > without any need to force things. > > > > If this is to be accepted, I'd amend the PRs from the other thread to > > follow those changes. > > > > Cheers, > > Guillaume > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- ------------------------ Guillaume Nodet
