What’s new in IntelliJ IDEA 2019.3 EAP7?

We have a fresh EAP build for the upcoming IntelliJ IDEA 2019.3. Come and have a look at the new improvements this new build has to offer!

As usual, the EAP builds for IntelliJ IDEA Ultimate are free to use but expire from 30 days of the build date.

Version Control

To resolve a bunch of usability issues, we removed ‘Checkout as’ and introduced a new unified Checkout action for remote branches and the ‘New Branch from Selected’ action for both remote and local branches.

Previously the IDE had the ‘Checkout as’ action that set the checkout branch as a remote tracked branch, as it called the git checkout -b localbranch remote/branch command.

But, it appears that the way it behaved was not what some users expected. A tracked branch is proposed as a default push target in the push dialog, and if a user decided to create a new branch, a feature branch, for example, from the start point of the selected release branch, usually the user would want to push this branch to a new remote branch, and not to the release branch.

‘New Branch from Selected’ action

To ensure clarity, we’ve introduced ‘New Branch from Selected’ – this action creates a new branch but no tracking is set.

The ‘New Branch from Selected’ action is available for both local and remote branches.

Brand new unified Checkout action for remote branches

Now when you invoke the ‘Checkout’ action on a remote branch, the IDE will silently create a new local branch, check it out, and set tracking of the selected remote branch if there is no local branch with the same name.
In cases where there is a local branch with the same name, it tracks remote but no commits will be lost during the checkout, the IDE will do a fast-forward update of the local branch (silently reset it to remote), and check it out.

If commits can be lost because of the reset, the IDE will show a confirmation dialog, and offer options to reset anyway or perform a Checkout & Update for the local branch.

The IDE will also show an options dialog offering to reset it anyway, and change the tracking or create a branch with a new name if the local branch tracks another remote branch.

You can invoke the Checkout action for remote branches either from the Branches popup or the Log context menu.

Better plugin management

The upcoming IntelliJ IDEA 2019.3 will allow you to install, uninstall, enable, and disable a theme plugin without restarting the IDE.

The keymap plugins also don’t need the IDE to be restarted anymore to work.

Spring Boot 2.2 support

The upcoming IntelliJ IDEA 2019.3 now supports Spring Boot 2.2, which includes support for @ConfigurationPropertiesScan. Also, ‘on’ and ‘off’ as boolean values in application.yml are supported as well.

More template languages can be injected

In the upcoming IntelliJ IDEA 2019.3, it is now possible to inject more template languages into your code, specifically: Pug (ex-Jade), Handlebars, EJS, and Slim. To inject a template somewhere in your code, press Alt+Enter, select Inject Language, and then pick a language from the list.

Template language injection

Please note that you need to install the plugin that supports the template language that you are going to inject into your code. Also, all template languages are supported in IntelliJ IDEA Ultimate only.

If you’re working with another template language in IntelliJ IDEA which is missing from the list above, please file a new issue in our tracker.

Try it!

Download the new IntelliJ IDEA 2019.3 EAP build from our website or update to it using the ToolBox App.

As always, any and all feedback is very much welcome in our issue tracker, discussion forum, and on Twitter!

Happy developing!

About Zlata Kalyuzhnaya

IntelliJ IDEA Marketing Manager at JetBrains. twitter: @ZlataKalyuzhnay ‏
This entry was posted in EAP Releases and tagged , . Bookmark the permalink.

25 Responses to What’s new in IntelliJ IDEA 2019.3 EAP7?

  1. Dusan Odalovic says:

    OMG, I really hope using VCS in Intellij will be easier than following the explanation from above.

  2. Andrey says:

    Nice improvements!
    Still hope old UI bugs will be fixed in this release https://youtrack.jetbrains.com/issue/IDEA-201369 :)
    By the way, why did you remove Git ‘Annotate’ action from context menu? It was move of most-used action for me.

    • Edoardo Luppi says:

      Out of curiosity why do you use annotate that much?

      • Dominik says:

        To find out who introduced the code (find out who is the best reviewer or who you can contact when not understanding something), when the code was introduced and to get information about the code using the commit message, the pull request, and the Ticket.

    • Dominik says:

      Annotate is still in the context menu if you right-click the line numbers on the left side of the code windows. That’s how I access it.

    • Dmitriy Smirnov says:

      There were no changes in Annotate. The action is still there – in the context menu, GIt – Annotate, main menu VCS – Git – Annotate, and the gutter context menu. If it does not appear for some reason, please submit a request with details – when it does not appear, etc.

  3. Mike says:

    Would be great if you could restore functionality that you had few years ago: remember push branch. As far as I remember it was in IDEA 14.
    Pull -> would use tracking branch – same as now
    Push -> would auto suggest previously pushed branch. Now it suggests tracking branch which is very annoying.

    My workflow:
    * always stay on master or on release branch. So that pull will always give you newest updates.
    * push is disabled on master/release. All pushes always go to feature/jira-XXX. For some projects they go to feature//jira-XXX.
    * in old IDEA I could just hit backspace 4 times and change jira number.
    * in new IDEA I need to type “feature//jira-” manually on every push :(

    • Mike says:

      Ups, brackets were auto-removed.
      Jira branch was: “feature/myusername/jira-XXX”.

    • Dmitriy Smirnov says:

      There are no plans to restore this behavior, it was intentionally removed.

      The described use-case should be solved with push.default = current git config, and its support in the IDE. See https://youtrack.jetbrains.com/issue/IDEA-100429

      • Mike says:

        push.default = current will be exactly same as current behaviour
        My local branch name is “master”. The branch I want to push to is “feature/myusername/jira-XXX”.

        If you suggest to name my local branch differently -> it is no difference. I have to type that long string manually either on branch creation or on commit. It is same annoyance :(

        • Dmitriy Smirnov says:

          If I get the use-case correctly, you need to base your work on master branch, with the ability to get new changes from there but push it to a different branch (origin/feature/jira-XXX)

          The git way of doing this is to checkout a new branch feature/jira-XXX that is tracking master, and push it to the corresponding branch on the remote. push.defaul=current is exactly about it.

          > it is no difference.
          There is. It is much more clear and consistent than remembering the last push target.

          > I have to type that long string manually
          You still have to type it somewhere. In the push dialog if not in the creation dialog.

          • Mike says:

            > There is. It is much more clear and consistent than remembering the last push target.

            I understand what you say. But people are people. I’ve seen similar to mine workflow used by many of my colleagues. The goal of IDE should be to help everyone (or at least majority), but not to dictate behavior.

            There are a lot of cases when you have to work on different tickets simultaneously. Instead of switching local branch multiple times back and force, you have all changes in one branch, but then you push to different branches. Once first commit merges it gets reintegrated to local branch with “git pull”. After that you can do next push.
            Yes, such workflow not always work, sometimes I do create local branches. But most of the time, especially for projects with just XML configs -> that’s the fastest way to stay on one local branch.

            >> I have to type that long string manually
            >You still have to type it somewhere. In the push dialog if >not in the creation dialog.
            Yes and no. During branch creation you might not yet have ticket number. Or during change you might have split tickets to subtask or move to other task.
            Plus during branch creation you always need to type it. And during push it used to put previous branch name, which was extremely convenient.

      • Mike says:

        Haha. I just tried new EAP.
        You actually managed to make my life even worse.
        You removed the option to name new branch from checkout dialogue.
        So now I have to use that stupid “New Branch” and then go to console and enable tracking from master.

        What’s going on? IDEA used to be greatly customizable. And now you are what? following Apple way? “you need to click 10 buttons instead of one because we like clean design with no buttons on main screen”.

        Can you at least make config option “show checkout dialogue”?
        When selected: checkout action will ask for local branch name.

        • Dmitriy Smirnov says:

          > You removed the option to name new branch from checkout dialogue.

          Without supporting the track-one-push-to-another configuration, settings tracking on checkout caused a lot of confusion. The new actions are clearer.

          The use-case you describe is clear and we will support it, but it is not only about checking out the branch with a different name.
          E.g. one of the ways to achieve this is ability to easily configure tracking from the UI. See https://youtrack.jetbrains.com/issue/IDEA-170083

          • Mike says:

            That ticket to change tracking branch is nice. But for past 5 years I never used it. All my local branches always track either master or release branch (or bugfix branch, which is kind of release branch).
            We have policy that PR always branched from top of master. So workflow is: “merge colleague’s change from remote feature branch, pull from tracked master/release, reset to master/release HEAD, force push to feature branch”.

  4. Aren says:

    When this blog will become mobile friendly?

    • Dmitry Konchalenkov says:

      Hi Aren! We are working on some improvements for the blog (including responsive design). We don’t have an ETA yet but please stay tuned for future updates!

  5. Xinky says:

    why you guys haven’t release the .gitignore plugin for 2019.3EAP?
    There is no git ignore plugin can use!

    • Dmitriy Smirnov says:

      Most of the gitignore functionality is now built-in, and some features of the plugin conflict with them. The plugin will be released when the changes needed to prevent the conflict are implemented.

  6. blackj0221 says:

    When DirectWrite API would be supported on Windows?

  7. Marten Deinum says:

    I thought the major theme for 2019.3 was performance and usability, this looks like new/updated features, what happend with the focus on the latter?

    One thing that would help a lot would be fixing IDEA-205094 (https://youtrack.jetbrains.com/issue/IDEA-205094) or one of the many duplicates thereof. It is annoying and decreasing developer productivity. There are more UI bugs/annoyances that decrease developer productivity, maybe the focus for 2020.1?

    • Dmitriy Smirnov says:

      The focus of 2019.3 is still on performance and usability. It will include a lot of fixes and improvements. This does not mean though, that there will be no other changes.
      This also does not mean we will not fix performance and usability issues in the future.

      The checkout actions update aims at solving usability issues the Checkout As action caused.

      The mentioned request is already fixed – https://youtrack.jetbrains.com/issue/IDEA-203148

Leave a Reply

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