IntelliJ IDEA 2020.1 EAP7: Improvements for Git, New Java Inspections

IntelliJ IDEA 2020.1 EAP was updated today. This post explains some of the recently added changes and different minor improvements.

Commit tool window & Commit dialog

Install Git from the IDE

New Java inspections

Auto-import of settings

Commit tool window & Commit dialog

Many of you have given us feedback about the Commit tool window since we enabled it by default for all users in v2020.1 EAP. Taking into account all the different opinions about the commit functionality, both inside and outside JetBrains, we’ve changed its behavior. Here’s how.

The Commit dialog is enabled by default again, as it was in v2019.3 and earlier. The commit features look exactly like they used to before v2020.1. This way, we don’t break the fashion in which millions of IntelliJ IDEA users are accustomed to committing things.

If you do prefer the Commit tool window, you can re-enable it by going to Preferences / Settings | Version Control | Commit Dialog and then selecting Commit from local changes without showing the Commit dialog (see the screenshot below). In the future, we will promote the new UI in the Commit dialog to allow in-place switching.

With that said, it’s worth mentioning that starting with v2020.1, all new users will still get the Commit tool window as the default way of committing changes. This means that if you start IntelliJ IDEA on a clean machine without using any configs from previous builds, you will see the Commit tool window by default. You can, of course, get back to the modal Commit dialog by unchecking the Commit from Local Changes without showing the Commit dialog option, which was mentioned earlier. See the image above.

Install Git from the IDE

Starting with v2020.1, you will no longer need to download Git manually if you don’t have it on your machine. For instance, when you choose to import a project from version control from the Welcome wizard, the IDE will not only look for Git on your machine, but it will also offer to download and set it up for you in the background:

Similarly, when you have a project that uses Git and the IDE cannot find the path to the Git executable, it will show you a notification and offer to download and install Git for you:

However, you will probably want to check your path to Git before downloading it once again. Remember that you can always do this, and you can configure other Git settings in Preferences / Settings | Version Control | Git.

New Java inspections

In v2020.1 EAP, we’ve added a number of Java inspections. For instance, the IDE now checks capitalization in SimpleDateFormat patterns, where it’s easy to make a mistake, and suggests a quick-fix:

Similarly, the IDE analyzes other date formatting cases, such as HH:MM, mm:SS, and MM/DD.

You will discover that the IDE now reports and suggests eliminating unnecessary escaping characters in string literals. It also finds more redundant method calls and adds other inspections.

Here is the list of all the new and updated inspections for Java in v2020.1.

Auto-import of settings

We have removed the Import Settings dialog for all existing users. Now, only users who do not have a config folder from the previously installed IDE versions, but who have accepted the License and Privacy Policy, will see the Import Settings dialog when the IDE starts for the first time.

Note that the path to the IDE’s config files has changed with v2020.1:

That’s it for today, but we will have more to tell you about in the next few v2020.1 EAP builds. Stay tuned!

Check out the release notes for the other closed tickets in this EAP build.

Happy Developing!

This entry was posted in EAP Releases and tagged . Bookmark the permalink.

19 Responses to IntelliJ IDEA 2020.1 EAP7: Improvements for Git, New Java Inspections

  1. unodgs says:

    Could you please restore release note link in update dialog (like it was in 2019.3)

    • Artem Sarkisov says:

      I’m looking for a workaround for that to restore it in the future builds. Do you prefer to read release notes rather than a blog post?

  2. Alex Katlein says:

    Why was the location of the configuration files changed?

  3. Pablo says:

    I do not like the change of config files.
    Please keep it under %HOMEPATH%.

  4. Tamas Herman says:

    Is there a way to display the diffs of a file in a commit, *next* to the modified file-tree (like it was before), instead of *below* the whole branches/commits/files columns?

    I love the side-by-side diff mode, but in this case I sometimes just switched into unified mode to still see the whole width of the file.

    Currently I can see the whole width, even in side-by-side mode, for sure, but I only see about half the lines and a lot of vertical space is just empty.

    As a rule of thumb, I would say horizontal space is cheap, vertical space is expensive…

  5. Christopher Rucinski says:

    Install Git from the IDE should be a Toolbox feature! Leave it for non-Toolbox users, but Toolbox should also allow me to manage my Git resource. Install, update, remove, move, etc.

    This could also work with managing Java, Python, Gradle, etc…

  6. Mike says:

    I so much loved inplace commit.
    But with some latest update you moved diff window into editor. In such case it became unusable to me.
    So I had to return back to commit dialog.
    Is there a plan to restore inplace diff? Or make i optional?

    > “We do believe though that switching to the new Commit tool window has a lot of benefits for instance, … it provides the full-sized diff in the editor.”

    This is not a benefit. It blocks my editor :(

  7. TheBestPessimist says:

    For those who like the non-modal git toolwindow + non-modal commit, but dislike diff-preview inside editor (and consider diff-preview should be located inside the toolwindow), you should check the following issues:
    https://youtrack.jetbrains.com/issue/IDEA-231847
    https://youtrack.jetbrains.com/issue/IDEA-231132

  8. Raziel says:

    Change the wording of the option: “Commit from local changes without showing the Commit dialog” to something like “Use old version control dialog”. An option’s wording should be self-documenting, that sentence doesn’t mean anything to anyone coming from an older version of IntelliJ/CLion who just wants their version control back to how it used to work.

    With regards to “In the future, we will promote the new UI in the Commit dialog to allow in-place switching”. Please don’t, no one wants a button or text to ‘promote’ the new commit tool window when they’ve explicitly said they don’t want to use it.

    Just have users pick which one they prefer on their first launch of the new version and have an option with simple wording to switch between the two options.

    • Dmitriy Smirnov says:

      Thanks for the feedback. The option will be renamed, to make it clearer and easier to find, and to correspond with promotions.
      Promotions will be easy to hide and won’t appear for those who explicitly disabled the new UI. It will also include in-place switch to turn the UI on or off.

      > Just have users pick which one they prefer on their first launch
      This won’t work, because most users have no idea what the new UI looks like as they have never seen it.

  9. Maxim Yanchenko says:

    Can we have the Commit dialog to behave like git add -p, i.e. any changes done in that dialog are NOT saved into the original files and only affect what’s committed? It’s a feature I use a lot from thew command line, and I expect IDE to replace the command line for me, at least for common scenarios, as git add -p really is.

    • Dmitriy Smirnov says:

      This will be highly confusing with the current implementation, so there are no plans to do so.
      However, full git stage support is on the roadmap

Leave a Reply

Your email address will not be published. Required fields are marked *