Rewriting lines just for the sake of cleaning up whitespace or removing closing braces alters the line.  It becomes harder to blame that line back through the original history of the project.  I think git.git did that once, and eventually got through the whole code base, but they also only had a few spots impacted.  Pretty much all of our javadoc has trailing whitespace errors.

Fixing all of this in the current code base is just code churn.  EGit and JGit are fairly mature code bases.  We try not to churn code unless there is some major benefit to doing it... and even then we want it incrementally in small units that can be digested.

Auto formatting of edited lines during save, I can't agree with, because sometimes I don't like the way the Eclipse formatter is laying out the line.  Sometimes I'll try to rename variables or pull something into a utility method to get a better line breaking, but sometimes I'll just give up and format the line to be as readable as I think I can make it.  If Eclipse is going to just wreck that on save, that sucks.

Removing unnecessary blocks, same thing, see my comment in your change that tried to enable that asking about unnecessary curly braces around a block with a large comment and a single line of code.

Regarding style issues being inefficient in the workflow, sure, it might be more difficult for someone who is new to the project to write code "in the project style".  But to be perfectly honest, our project is old enough that project style is "match surrounding code as best as you can", and there's a lot of that code present to use as an example.  This is good practice in almost *any* project you work on.  

If a contributor can't be bothered to match surrounding style, we also have to wonder how much they really understanding the neighboring code that may or may not be affected by the change they are trying to make to the logic.

Further, we have contributors to JGit who aren't Eclipse users.  They can't rely on Eclipse auto formatting, auto save, auto bug fix, auto whatever.  If the problem here is that "match surrounding code" isn't a sufficient rule for style and a more detailed guide is needed, we need to document that for any contributor, and especially for those who prefer not to use Eclipse.  Yes, that's horrible, not using Eclipse on an Eclipse hosted project, but that's the reality, JGit has contributors who aren't Eclipse users, and we'll lose them if the only way they can be an effective contributor is to switch their IDE and tools.