Enshittification: JetBrains macht IntelliJ's Commit-Workflow und "Local Changes" kaputt

Enshittification, ein neumodischer Begriff, der ausdrückt, dass Programme und Services heutzutage immer mehr an Qualität verlieren.

Sei es Google, Amazon, … nun hat es leider auch JetBrains erwischt, die Schöpfer von IntelliJ.

Frühzeitige Vorwarnung hatte, wer EAP-Versionen nutzt

Im Early Access Program (kurz EAP) stellt JetBrains neue Versionen ihrer IDEs zur Verfügung, bevor sie allgemein der großen Öffentlichkeit zugänglich gemacht werden. Eine super Sache, die neuesten Funktionen schon im Vorfeld zu testen/haben, wenn man mit dem ein- oder anderen Bug oder auch mal einer unbenutzbaren Version leben kann. EAPs kommen nach einer Weile, wenn die nächste Version in Entwicklung ist, im Wochenzyklus raus (gefühlt, frag mich nicht, ob das ein fixer Zeitplan is, egal, darum gehts nicht).

Mit Version 2025.1 EAP 4 wurde das "Local Changes"-Tool-Window und der Commit-Dialog stillschweigend(❗) entfernt.

JetBrains veröffentlich zu jeder EAP-Version einen Blog-Beitrag mit den Änderungen und neuen Features. Der Blog-Beitrag zu EAP 4 enthält aber keinen einzigen Satz über diese Änderung.

Unter dem Blog-Artikel im Kommentarbereich posten Nutzer über diesen Fakt. Jedoch keine Reaktion von JetBrains.

• 

• 

Commit-UI beschissen wie in Visual Studio Code

Nichtsahnend nach dem Update auf EAP 4 – ich hatte ja den Blog-Artikel mit den Changes gelesen –, drücke ich nach getaner Arbeit wie gewohnt Strg+K, um den Commit-Dialog zu öffnen. Nichts passiert. 🤨

Das "Project"-Tool-Window, dass sich normal in der oberen linken Ecke befindet und die gesamte Verzeichnisstruktur meines Projekts anzeigt, wurde aber durch ein "Commit"-Tool-Window ausgetauscht.

WTF!? – "Macht jetzt JetBrains denselben Scheiß wie Microsoft und seinem Visual Studio Code?!" war mein erster Gedanke. Ich musste geschäftlich mal für einen bestimmten Use-Case (und zum Glück zur eine sehr begrenzte Zeit) VS Code nutzen und war entsetzt wie beschissen die Commit-Oberfläche da ist: Eine kleine einzeilige Text-Box in einem kleinen Toolwindow auf der Seite.

• 

Wie soll ich da meine Commit-Message sauber entwickeln, d.h. tippen, prüfen und komplett sehen?! Der Workflow "einen Commit machen" sah da so aus, als ob man Entwickler dahin trimmt, dass sie schnell zwei oder drei Worte tippen und dann mit Enter direkt abschicken.

Ich hab damals nicht ausprobiert, ob Enter wirklich direkt den Commit abschickt, sondern ich hab damals auf der Konsole git commit benutzt. Auf dem obigen Screenshot, den ich aus dem Manual von VS Code hab, sieht man, dass es wirklich per Tastatur geht, mit Strg+Enter. 😱

Junior-Entwicklern predige ich,

• sie sollen sich Zeit für den Commit nehmen,
• die Commit-Message entwickeln, während sie nochmal alle veränderten Files im Diff durchgehen (und ggf. Fehler oder offene TODOs bemerken und damit den Commit abbrechen) und zeitgleich die Commit-Message notieren.
• je nach Größe und Impact der Änderungen mehrzeilig (in Stichpunkten) diese in der Commit-Message festhalten.

Ein derartiges UI vermittelt genau das Gegenteil: Rotzt einfach schnell einen Einzeiler hin. Ihr könnt sogar direkt per Tastatur abschicken, damit noch schneller geht. 🤦‍♀️

• 

IJPL-177161 – Bug-Report(s) im JetBrains Bug-Tracker

Die Anfänge des Tickets (7. Februar)

Nachdem ich das katastrophale "neue" UI in IntelliJ gemerkt hab, bin ich natürlich sofort in den JetBrains Bug-Tracker und hab gesucht. Musste nicht lange suchen, bis ich IJPL-177161 fand.

Das Ticket hieß zu diesem Zeitpunkt (8. Februar 2025) noch "Modal commit interface cannot be activated in 2025.1 EAP4". Angelegt wurde es einen Tag vorher, am 7. Februar 2025, direkt am selben Tag, als EAP 4 veröffentlicht wurde.

Mein Take-Away ist: Entwickler, die in ihrem Workflow gestört waren, haben das sofort bemerkt und reported.

Workaround

Ein User im Forum postete direkt am selben Tag, weniger als 6 Stunden nach Ticketerstellung einen funktionierenden Workaround:

# custom IntelliJ IDEA properties (expand/override 'bin/idea.properties')
vcs.force.modal.commit=true

Quelle: Kommentar von machak in IJPL-177161

"Local Changes"-Tool-Window war verschwunden

Zusätzlich zum gestörten Commit-Workflow war auch das "Local Changes"-Tool-Window, das die aktuell geänderten Dateien anzeigt und erlaubt, zu diesen zu springen und das "Shelf"-Tool-Window (was ich nur sehr selten benutze, seit es git stash gibt) weg. Ich habe hierzu ein separates Issue im Tracker angelegt: Tool window "Git" is missing "Local Changes" and "Shelf" tabs in latest EAP.

Dieses Issue wurde innerhalb von weniger als 2 Stunden als Duplikat von IJPL-177161 geschlossen.

Hierzu ein paar Überlegungen: Ich, als Entwickler, mag es nicht, wenn Tickets mehrere Issues in sich vereinen. Ein Entwickler möchte normal jede Kleinigkeit einzeln, damit man diese auf andere Devs aufteilen und zu unterschiedlichen Zeitpunkten implementieren kann. Entsprechend war meine Intension, den IntelliJ-Devs entgegenzukommen und nicht in das bestehende IJPL-177161 ein "ach übrigens, die Tool-Windows fehlen auch" als Kommentar reinzuposten.

Mein Issue nun als Duplikat zu schließen, zeigt schon, dass nicht wirklich gewünscht war, die Fehlentwicklung (so nenne ich das neue UI im Folgenden mal) einzugestehen und zurückzurudern.

Mein Post im Ticket

Ich habe zusätzlich in IJPL-177161 auch noch einen langen Text mit Argumenten und Insights in meinen Entwicklungsworkflow gepostet:

Yet another change nobody wants, and hinders productivity. 🙈

I've been using IntelliJ for over 15 years, I am working with this application 8-10 hours a day, every day, 7 days a week (yes, I code in my spare time, too). In general, such changes do not help as it requires to readjust workflow and actions one is doing thousands and thousands of times, and now suddenly they are different.

I want to add my perspective to the issue:

Focus on committing your code
Committing one's changes is the most important part of coding. You should put your full attention to it. I preach to my junior devs to not rush committing, taking your time to reflect everything you did and writing it all done into the commit message. Having the commit window put "aside" in some tool window, the "Commit" button every-ready just reinforces this "fast, fast" behavior.
The modal commit dialog forces a dev to put his focus onto checking the changes once again (checking the diff either inside the commit window, or better yet opening separate diff windows), and writing down the commit message. No distraction possible, no coding possible, until the dialog is closed.

The commit dialog box can be resized. I have no idea how small it was in default. I resized it to about 75% of the screen to be large enough to write my message.
(Yes, I tried the workaround with the new non-modal tool window to configure it a window. Horrible, there is no padding around the window, the "Commit" button dangerously is not separated in any way).

And, as already mentioned by other people here: You are focusing what's centered in the screen/application. Having the commit window in some corner or edge does not fit. If you just wanted to make it non-modal, I do not understand why you did not make it a tab at least.

"Local Changes" disappeared
Even worse to the new tool window is the side-product the "Local Changes" tab disappeared (I assume, in favor of the non-modal commit). I filed a separate issue IJPL-177268 in case this is an unrelated bug.

The "Local Changes" tab is the MOST IMPORTANT thing I work with in IntelliJ. It always has all my changes, I can use it to navigate to my currently-in-work files, I can open diff viewer from it to see what I have done/changed to far.
If anyone now says "there is the 'Project' tool window": Yes, there is, and you can set it to a similar view. However, it serves a different purpose. The "Project" tool window allows me to see my whole project, jumping to files I just need to read for reference, but are not part of my current work. And of course, to open a file that I want to start working in.

I need both of these tool windows open simultaneously! Having to switch around the mode in the "Project" tool window simply does not work.

The "Local Changes" tab is open with me for 100% of my time. I only need to switch to Git Log, and when I am done, I immediately switch back to "Local Changes". I need this view!

A personal remark
Having discussions with many different people at work, everybody is using an IDE of their choice. M$ Visual Studio Code is highly used. One argument I have always defended, and is accepted by colleague: VSC is good, but IntelliJ has the best Git integration! From committing to displaying the Git graph. What I am saying? Even the VSC guys envy this part of IntelliJ.

The new non-modal tool window now is just as stupid as VSC's commit UI: A small text input field and a commit button next to it to make it easy to spew out a commit fast, instead of focusing on a high-quality commit.

---

I really hope, you guys reconsider before applying this change to a final 2025 version. 🙏

Quelle: Kommentar von mir in IJPL-177161

JetBrains-Guys freuen sich normalerweise über Anwendungsfälle. Der Post wurde von der Community auch entsprechend positiv bestätigt (Stand wie ich diesen Artikel hier schreibe: ➕ 52, 👍 32, 💯 23), daraus lese ich, dass meine Einstellung nicht völlig falsch is 😉

Viele Entwickler haben ähnliche Kommentare wie ich geschrieben und nicht verstanden, was an dem neuen UI nun besser sein soll. Im Gegenteil, alle haben die Verschlechterungen kritisiert und dass sie nicht mehr ordentlich arbeiten können.

Unverständnis war auch deshalb da, dass so ein tiefer Eingriff gemacht wurde, ohne Feedback von der Community – oder schärfer formuliert: – den zahlenden Kunden eingeholt wurde. Ich zitiere hier mal einen der Kommentare:

This is yet another disappointing and unnecessary change :( Do the product team ask for feedback or listen to its users before deciding on changes like this? This seems like yet another part of this new UI idea that a lot of people don’t like and don’t want. I guess maybe I should blame myself for turning of Send usage statistics.

Quelle: Kommentar von mads lundemo in IJPL-177161

Kritik aus den eigenen Reihen?

Einer der Kommentare, die die Vorteile des alten Commit-Dialogs und die Nachteile der neue Oberfläche erörtern, stammt von Leonid Bushuev, einem Software-Entwickler von JetBrains:

• 

• 

Erstes Statement von JetBrains (13. Februar)

Das Ticket wurde nach knapp einer Woche, am 13. Februar 2025, auf Status auf "Answered" gestellt, nachdem jemand von JetBrains erstmals zum Sachverhalt gepostet hatte.

Die Signifikanz des Status ist: Wenn das Ticket auf "Answered" steht, kann man als Benutzer nicht mehr dafür voten. In den Kommentaren schlägt sich das nieder, das Ticket stand IIRC bei nur etwa 30 Votes, obwohl es viel mehr erboste Kommentare gab.

Normalerweise ist die Voting-Zahl wesentlich höher, als die Anzahl der Kommentare, da viele zu faul/zurückhaltend sind, einen Kommentar zu schreiben, während ein Klick auf "👍" keine große Hemmschwelle ist.

JetBrains' Antwort, gepostet von Ilya Kalibrov (von mir zusammengefasst, siehe Original im Screenshot unten):

• Performance und Nutzererfahrung: Angeblich gibt es Altlasten ("technische Schuld"), die man nicht anders beseitigen kann, die u.u. auch Lags und Performance-Probleme machen.
  • Meine Antwort: Käse! Klar hat man technische Schuld, aber die kann man immer lösen, ohne ein komplett neues und anderes Feature zu bauen, was keiner will! Von Performance-Problemen am modalen Dialog und den eliminierten Tool-Windows hab ich über die viele Jahre und Jahrzente nie was gemerkt.
• Remote-Development: Für Remote-Development steht das modale Dialogfenster im Weg
  • Meine Antwort: Kann ich nix dazu sagen, wie Remote-Development funktioniert, benutz ich nicht. Allerdings wenn wie zuvor zwei Varianten des Commit-Dialogs (später dazu mehr!) koexistieren können, so kann man das auch so bauen, dass eben nur für Remote-Development die neue Oberfläche verwendet wird. Für "normale" Programmierung kann weiterhin die bestehende Oberfläche verwendet werden.
• Das non-modale Commiten wurde schon vor einigen Jahren eingeführt und jetzt ist es der Default für die meisten Nutzer. "Wir wissen, es ist nicht perfekt, aber wir verbessern es kontinuierlich".
  • Meine Antwort: Ober-Bullshit!! Ja, das neue UI ist in Wirklichkeit nicht neu (ich schreib gleich mehr dazu…). Als Argument aber anzuführen, dass die meisten Nutzer das nun nutzen, ist sehr vermessen, da viele dieser "meisten Nutzer" den alten Commit-Dialog gar nicht kennen. Es ist eher so, dass durch den Shitstorm, der nun entstanden ist, einige dieser "meisten Nutzer" überhaupt erst erfahren haben, dass es eine bessere Oberfläche, den alten Commit-Dialog gibt/gab.

• 

UI-Rückschritt, der 5½ Jahre in Entwicklung war

Das "neue" UI in IntelliJ ist nicht wirklich neu. Bereits vor 5½ Jahren hat JetBrains mit Version 2019.2 EAP 5 einen ersten Versuch gemacht, dass man direkt aus dem "Local Changes"-Tool-Windows committen kann.

• 

Über die Zeit ist das Feature dann produktiv gegangen und verfeinert. Wenn ich sage "über die Zeit", ist gemeint: JetBrains nimmt ein Feature, was innerhalb von EAP entwickelt wurde, immer mit der nächsten Version live, egal wie ausgereift es ist. Das habe ich innerhalb vieler Jahre als EAP-Nutzer gelernt.

Mit 2019.2 ging das neue Feature dann produktiv. Im Blog-Beitrag heißt es:

It is now possible to commit from the Local Changes tab; just enable the option Commit from the Local Changes without showing a dialog at Preferences / Settings | Version Control | Commit Dialog.

Man beachte hier: Das neue Feature wurde nicht aufgezwungen, sondern konnte explizit aktiviert werden.

Ich hatte während der EAP-Version das schon ausprobiert und für nicht gut befunden und hatte es auch nach dem Release von 2019.2 nicht aktiviert. Ich war froh, dass es optional ist und meinen Entwicklungs-Workflow nicht behindert.

"Diskussion", aber Community komplett ignoriert

Ilya hat auf einige Beiträge geantwortet, wo er das meiste zwar ignoriert hat, aber versucht hat, die Fehlentwicklung durch "du kannst ja dies und das einstellen" zu mitigieren versucht. Z. B. kann das neue Tool-Window auch als eigenständiges Fenster extrahiert werden. Ich hatte das während der EAP-Phase ausprobiert, Katastrophe. Da kleben die Button am Rand des Fensters.

Viele Nutzer schildern ihre Use-Cases und konstruktives Feedback, teilweile in mehreren Bildschirme langen Posts. Die Aktivität von Ilya (=JetBrains) hält sich aber beschränkt auf Einzeiler à la "Danke für das Feedback, kannst du (noch) mehr Informationen posten?"

Konkrete Fragen der Community werden aber konstant ignoriert. Zum Beispiel diese Interaktion:

Please explain in plain words what feature of the commit modal is now better in the new UI. What problem and improvement does it bring for the user? Not how to mitigate what is lost.

Also if you can make floating windows, why can't you make the commit dialog as that instead of apparently the terrible legacy modal dialog code? It would actually fix the only limitation of the current commit dialog which is that it's blocking the rest of the UI.

Drei Fragen:

• Welche Features im neuen UI sind nun besser?
• Welche Probleme/Verbesserungen bringt es für die Nutzer?
• Wenn man "floating windows" machen kann, warum kann man diese Technik nicht auch für den Altlast-Code im Commit-Dialog einsetzen, um ihn non-blocking zu machen?

Ilya's Antwort:

@Lionel Cox Could you please make a list of things that are missing right now in non-modal compared to modal commit?

I went through your comments, and these are things that I highlighted:

• […]

Er antwortet mit einer Gegenfrage, ignoriert alle drei gestellten Fragen und fasst dann die Inhalte von Lionel aus seinen vorherigen Posts zusammen.

Quellen:

• Kommentar von Lionel Cox in IJPL-177161
• Kommentar von Ilya Kalibrov in IJPL-177161

Zweites Statement von JetBrains (12. März)

Am 12. März, mittags, schreibt Anastasia Ronzhina von JetBrains einen kurzen Post, dass unser Feedback gesehen und wertgeschätzt wird. Sie finalisieren eine ausführliche Antwort im Laufe des Tages, um unsere Punkte zu addressieren und nächste Schritte.

Sie entschuldigt sich für die Wartezeit.

Original-Post auf Englisch:

Hey everyone, we see all your feedback and truly appreciate you sharing your concerns. We’re finalizing a detailed response today to address your points and clarify our next steps.

We apologize for the delay—taking the time to evaluate the situation properly was necessary to make decisions. We’ll be back soon with more details. Thank you for bearing with us

Quelle: Kommentar von Anastasia Ronzhina in IJPL-177161

Am Abend, um kurz nach 18 Uhr (btw. alle Uhrzeiten sind Ortszeiten von mir, wie sie YouTrack umrechnet), kam das versprochene Posting. Sehr ausführlich, man muss mehr als 2 Bildschirme scrollen. Der volle Post ist hier zu finden.

Die Quintessenz zitiert:

TL;DR: Roadmap for Commit Experience Improvements

1. We’re bundling the modal commit plugin in the next release candidate, allowing continued use of the modal commit without having to search for or download the plugin.
2. We’ll introduce incremental improvements to the non-modal commit experience, based on feedback, including better keyboard navigation, an improved commit tool window.
3. We’ll investigate a solution for distraction-free commit process.
4. The modal commit dialog will still be available as a plugin during and after this transition.
5. We’re planning to unbundle the modal commit plugin in 2025.2, after completing mentioned improvements and gathering more feedback to ensure a smooth transition.

• 

Am 14. März, 2 Tage nach Anastasia's Post, wurde der Ticket-Titel dann umbenannt von "Modal commit interface cannot be activated in IntelliJ IDEA 2025.1 EAP4" zu "Modal commit moved to a separate plugin in 2025.1 - Discussion".

• 

Das Plugin

Bereits am 10. Februar (also 3 Tage vor Ilya Kalibrov's Antwort) hatte Anastatis Ronzhina IJPL-177359 eröffnet mit dem Ziel, den modalen Commit-Dialog (kein Wort vom "Local Changes"-Tool-Window 🤷‍♂️) in ein unbundled Plugin zu verschieben:

Some users strongly prefer the modal commit experience and are not ready to switch to the non-modal workflow. To accommodate them, we will provide an option to enable the modal commit through an unbundled plugin. This plugin will allow users to restore the modal behavior if they choose, though it will not be officially supported. However, users will still be able to submit PRs for improvements or fixes

Man beachte auch den gehässigen Wortlaut "Some users […] are not ready to switch", als ob das ein Problem der Nutzer wäre, wenn das UX verunstaltet wird. 🖕

Im Statement vom 12. März wird nun die Roadmap mit dem Plugin vorgestellt. Wer hier genau hinsieht, bemerkt folgendes:

a) Es wird betont, dass das Plugin nur bis 2025.2 supported wird und von einer "Transition" gesprochen. Danach wird "unbundled" und nicht mehr supported, damit die Community es supporten kann:

Once these enhancements are in place, and we’ve gathered additional feedback, we plan to finalize the transition in 2025.2 by unbundling the modal commit plugin from the IDE. However, we will continue to support the plugin throughout the year to ensure a smooth transition for you.

In IJPL-177359 heißt es:

This plugin will allow users to restore the modal behavior if they choose, though it will not be officially supported. However, users will still be able to submit PRs for improvements or fixes

b) Wenn man sich das Plugin mal genauer anschaut, erkennt man, dass darin überhaupt kein Code ist. Es aktiviert also nur versteckten Code, der immer noch (un-refactored) in der IDE vorliegt.

• 

• 

• 

Das kommt uns sehr ähnlich vor, wie damals mit dem "Classic UI", wo sich auch viele Nutzer beschwert hatten. Laut einem Post im Ticket (ich hab das nicht überprüft), gibt es das passende Plugin für das "Classic UI" seit fast einem Jahr und JetBrains hat auch hier kein Refactoring gemacht, sondern lediglich einen "verstecktes Setting aktivieren"-Wrapper in das Plugin.

Wenn das mit dem "Modal Commit Dialog"-Plugin genauso läuft und nach einer vergleichsbar kurzen Zeit das Plugin entfernt wird, ohne vorher den Code zu verschieben, kann die Community das Plugin auch nicht selber maintainen. Die Folge, dass wir damit trotzdem auf die Fehlentwicklung "non-modal Commit" genötigt werden! (Eine Form von "hoffentlich haben die's in einem Jahr vergessen, bis dahin geben wir ihnen das Plugin, damit sie die Klappe halten" 🤐)

EAP-Umfrage (31. März)

Am 31. März hab ich eine Mail bekommen – wie üblich – eine Umfrage zur EAP-Version auszufüllen. Die Umfrage sieht eigentlich jedes Mal gleich aus: Es werden die neuen Features ausgelistet und überall gefragt, ob man sie benutzt/getestet hat bzw. ob sie für die Arbeit relevant waren, sowie nach einer Bewertung gefragt und ein Freitext-Feedback-Feld angeboten.

Für mich nicht erstaunlich: Die kontroverse Fehlentwicklung "Neues Commit-UI" wurde nicht erwähnt! Man konnte lediglich im allgemeinen Freitext am Ende seinen Frust und Unverständnis über diese Tatsache loswerden.

Positiv hätte man hier auftreten können und konkrete Fragen à la

• "Do you know the modal commit dialog?",
• "Which workflow do you prefer? Modal dialog or non-modal tool window?"

stellen. Ne, gar nix. Stattdessen, wurde einfach sturr released. (Keine Überraschung für mich. Wie schon geschrieben: Bis jetzt sind EAP-Entwicklungen immer final released worden, no matter what!)

Release von 2025.1 (16. April)

Am 16. April wurde 2025.1 final released, siehe JetBrains' Blog-Beitrag.

In den Blog-Beitrag schafft es die Fehlentwicklung mit einem Einzeiler unter "Version control systems":

We’re refining the non-modal commit workflow, and we’ve moved the modal commit interface to a plugin, which is bundled in v2025.1 and can be enabled in Settings | Advanced Settings | Version Control | Git.

Nein! Ihr habt nicht das modale Commit-Interface in ein Plugin verschoben. Ihr habt das non-modale Commit-Interface zwangsaktiviert und die Option, um auf das modale Interface umzustellen, ausgebaut. Das Plugin setzt lediglich das entfernte Setting.

Mit der Beta-Version (kurz vor dem Release) ging dann auch der Workaround nicht mehr. Dafür haben wir in der Release-Version nun das (zeitlich-begrenzte) Plugin. Wie ich für Screenshots vorhin die finale 2025.1 installiert hatte, ging der Workaround wieder, auch mit deaktiviertem Plugin.

Dritter großer Post von JetBrains (18. April)

Zwei Tage nach dem Release auch wieder eine Reaktion von JetBrains im Ticket: Am 18. April hat Anastasia einen weiteren Post im Ticket verfasst.

Btw. bis dahin war von JetBrains absolute Funkstille. Kein Post zwischen 12. März und 18. April.

Meine Zusammenfassung des Posts:

• Da man zwischenzeitlich 2025.1 final released hat, eine Erklärung/fürs Protokoll, dass man darin per Benachrichtigung den Nutzern einen Link zum Ticket IJPL-177161 gibt, damit sie informiert sind.
• Das Plugin ist nun supported und mit der IDE gebundelt. Man muss nix separat installieren.
• "“Local Changes” is not going away." was besonders für mich persönlich einen kleinen Lichtblick gibt, da bisher immer nur über den Commit-Dialog diskutiert/gepostet wurde, niemals über das Verschwinden des "Local Changes"-Tool-Windows.
• Eine Erinnerung, dass JetBrains ihre eigenen IDEs benutzt (siehe Dogfooding).
• Ein besonderer Dank an einzelne User im Ticket, die ihre Use-Cases dargelegt hatten.
• 2025.2 ist für Mitte Juli geplant. Im Mai und Juni will man entsprechend Verbesserungen einbauen und nach Feedback der Community fragen.

Ich sehe den letzten Punkt wieder sehr kritisch, weil man das auch so lesen kann: "Wir bauen ein paar Kleinigkeiten um, ignorieren aber das Overall-Feedback und pushen weiter unseren Workflow durch. 'Nach Feedback fragen' ist wie dieses Ticket hier ein Alibi, weil ihr zwar posten könnt, wir es aber einfach ignorieren. Und mit 2025.2 ist das Plugin dann eh weg und ihr habt schon ab Juli Pech gehabt. 😝"

Fun fact: "We don't have enough resources"

Während des ganzen Shitstorms hab ich ein Notify für ein JetBrains-Issue bekommen, was ich vor fast 5 Jahren angelegt hatte und bis dato ignoriert wurde: IJPL-78683.

Ein Bot fragt mich, ob das Ticket noch relevant und reproduzierbar ist.

Meine Antwort: Keine Ahnung. Auf das Projekt, wo es damals vor 5 Jahren aufgetreten ist, hab ich schon lange keinen Zugriff mehr. Habt ihr das nie selber ausprobiert gehabt bzw. wollt das nicht selber ausprobieren?

Erst darauf antwortet mir ein Mensch

Unfortunately, we don't have enough resources to try to reproduce each reported case, therefore we need to work on a prioirty/severity basis.

Quelle: Kommentar von Ivan Pajic in IJPL-78683

Die richtige Antwort darauf, die ich nicht mehr im Ticket gepostet hab, aber jetzt hier in meinem Blog schreibe:

Wenn ihr euch nicht um irgendwelche Scheiß-Features kümmern würdet, die kein Mensch braucht und kein Mensch will, dann hättet ihr auch mehr Zeit, um Bug-Reports zu bearbeiten! 😉

Guckt man sich die Webseite von JetBrains an, is alles voller AI-Käse. Was das wohl Zeit und Ressourcen frisst, die man besser einsetzen könnte, um die Qualität der bestehenden Produkte zu verbessern und Bug-Reports zu bearbeiten.

• 

• 

Wie geht's weiter?

Das Ticket ist Stand heute, 28.4.2025, das Ticket mit den meisten Kommentaren im ganzen JetBrains-Tracker (und die Ticketnummern sind 6-stellig!). Das sollte zu denken geben! Neben konstruktiver Screenshots zu Workflows und UI-Vorschlägen ist das Ticket auch voller Meme-Attachments.

• 

• 

Mein Abo läuft Juli aus. Ich weiß noch nicht, ob ich verlängere…

JetBrains' IntelliJ ist leider ohne Alternative. Es gibt keine vergleichbare IDE, die soviel Assistenz bietet. Und nein, Visual Studio Code ist keine Alternative, da haben mir die wenigen Minuten oder paar Stunden gereicht, die ich es nutzen musste!

Früher oder später brauch ich eine aktuelle IDE, um mit den Frameworks/Languages/Tools up-to-date sein. D. h. ich werde um IntelliJ nicht herumkommen. Aber evtl. reicht es, z. B. alle 5 Jahre einmal eine Lizenz zu haben, nicht mehr permanent. Oder die Community-Edition und zusätzlich andere Tools.

Einen kleinen Lichtblick habe ich, dass JetBrains Verbesserungen machen will. Besonders der "Wir entfernen 'Local Changes' nicht"-Post lässt mich hoffen, dass man trotz der Fehlentwicklung noch arbeiten kann. Wenn Commiten nicht mehr komfortabel geht, da gibt es andere Tools oder auch die Kommandozeile. Für mich ist die Schmerzgrenze erreicht, wenn ich nicht mehr sehe, welche Dateien ich geändert habe bzw. einfach zu diesen hinspringen kann.

Ich möchte nicht zuviel über 2025.1 schreiben, da ich bis auf die wenigen Ausblicke in der EAP immer mit dem Workaround gearbeitet hatte und damit von der Fehlentwicklung verschont geblieben bin. Was mir jetzt auf die Schnelle, wo ich diesen Artikel hier schreibe, schon auffällt: Selbst mit dem Plugin aktiviert, hab ich zwar den Commit-Dialog und das "Local Changes"-Tool-Window wieder, aber "Local Changes" hat dennoch eine Änderung drin. Und diese Änderung ist auch wieder negativ: Die Toolbar in "Local Changes" wurde von links nach oben verschoben. Warum?! Jetzt hat eine oder zwei Dateien weniger Platz 🤦‍♂️ …und man muss sich wieder umgewöhnen, weil das Auge gewohnt war, auf die linke Kante zu gucken, wo auch der Tab "Local Changes" steht. Ich schau jetzt immer erstmal ein paar Pixel daneben. 😩

• 

• 

Ich werde jetzt – nachdem ich diesen Artikel hier geschrieben hab – 2025.1 nochmal eine Chance geben. JetBrains hatte zwischenzeitlich auch einen Support-Artikel in ihre Wissensdatenbank, wie man das non-modale Interface konfigurieren kann, dass es sich wie das modale verhält.

Ich bin gespannt, wie es weiter geht…

Mein Aufruf an alle, die bis hierhin durchgehalten haben und diesen langen Artikel gelesen haben: Wenn ihr auch IntelliJ oder eine andere JetBrains-IDE nutzt und das genauso seht wie ich, geht ins YouTrack und postet eure Meinung, kontaktiert JetBrains über Social Media und verschafft euch Ausdruck.

---

Was denkt ihr? Nutzt ihr IntelliJ (oder eine andere JetBrains-IDE, die bald/schon unter dieser Fehlerentwicklung leiden wird)? Was ist euer Workflow? Habt ihr euch an der Diskussion in IJPL-177161 beteilt?

Was ist eure Meinung?