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.
it seems git blame --ignore-revs in Git 2.23 does what we need: https://michaelheap.com/git-ignore-rev/ 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 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: [email protected] For additional commands, e-mail: [email protected]
