> I think Dawid argued that the check is good to notify the > committer that there may be uncommitted changes, but I doubt this helps. > A warning would be fine. >
Reviving the dead (beetlejuice, beetlejuice, ...) but here's an example where validation.git.failOnModified helped me figure out that google java formatter is broken on JDK 23 - https://github.com/google/google-java-format/issues/1153 This happened on an automated CI build under the new JDK. I can understand why people can get frustrated by this option (and it's fine to move it to CI only) but I just wanted to point out that the design of this check was to make sure "precommit" actually verifies that no local changes are present (so that you're "precommit-testing" an actual commit to be made). If you're git-savvy and prepare your commit by adding any changed files using git add, they're staged/cached (waiting for the actual git commit) and then the gradle check wouldn't fail, expecting you to commit them, eventually. It only fails on truly locally modified or unknown files. The fact people are complaining is probably the best evidence it was not clear and perhaps not needed. Dawid
