2019.2 GIT branch Compare With Current changed

Answered

Previous to 2019.2, the GIT branch Compare With Current feature would display a popup with current branch in a top pane and the selected branch in the bottom.  In each pane would be a list of commits that did not exist in the other.  I found this to be extremely helpful when determining merges.  In 2019.2, this feature now just lists the updated files from the selected branch.  Is there any way I can get the old way of comparing branches?

Thanks a bunch.

76
71 comments
Official comment

The old Compare dialog will be restored in the 2019.2.3 release.

We understand the new implementation brought in several Usability issues, and apologize for that, we could do better. We are restoring the dialog in 2019.2.

However, we believe improving the Compare branches feature is the right thing to do, so we plan to solve all the usability issues of the new implementation and use the fixed version in 2019.3. Several fixes and improvements are already done, but there are more to do.

The issues we plan to address include but are not limited to:

  1. Inability to see the comparison result at a glance. The solution TBD yet, https://youtrack.jetbrains.com/issue/IDEA-222141 can be a part of it.
  2. One-direction comparison only - https://youtrack.jetbrains.com/issue/IDEA-209664 fixed, will appear in the second 2019.3 EAP
  3. Confusing empty view on the action invocation - https://youtrack.jetbrains.com/issue/IDEA-216382 fixed, will appear in the second 2019.3 EAP 
  4. "Missing" File comparison - the feature has not been removed but moved to the separate Show Diff with Working Copy action. This will be made easier to find. 

The feedback on the new features and changes is always welcome.

No. there is no way to get the previous view.

An option for reverse comparison will be added soon. See https://youtrack.jetbrains.com/issue/IDEA-209664

-59

Good day, dear IntelliJ!

I was looking for the same issue as the topic starter after updating to 2019.2. 

I have to say that I found the new feature ambiguous and misleading. 

When I click "compare with current" I expect to see the actual difference between 2 branches (as it was before), but now I'm taken to VCS log which shows me only the unidirectional difference, e.g. commits that exist in the branch being compared and not in the current, but does not show commits that exist in the current branch but do not exist in the one being compared.

That makes the tool extremely clumsy for the purpose of comparing 2 branches because it makes me to perform one comparison, then switch branches and compare again.

I know about a new option `show diff with working tree` that partly covers the good old "compare with current",  but still both new features are confusing for those who have experience with older versions.

>An option for reverse comparison will be added soon

Hope for that option as default for "compare with current", thanks!

33

I was a heavy user of this feature, and I think it's one of the things that really made IntelliJ stand out amongst it's peers.  The new feature is pretty weak by comparison.

Please add this back soon!  Imagine a number of folks (including myself) will need to consider downgrading to 2019.1 otherwise.

42

Hey phpStorm devs!

Please bring back the previous branch comparison feature ASAP!

This feature in the newest version 2019.2 now pretty much unusable and unreadable.

Before, there was a clean and concise view of differences, now it's a usability disaster.

Thanks!

34

Pleased to see other devs like the previous, more intuitive feature.  I'm wondering why in the world JetBrains felt this needed to be "fixed".

 

28

The old popup dialog also contained a tab showing the actual changed files between one branch and another. Please bring back the old dialog, the new one is completely unusable.

29

What exactly is unreadable and why? Why is it unusable?

Yes, the UI has changed but the comparison still shows you the same list of commits, as the dialog used to. And it is even more readable now and has more details. The only difference is that by default a one-way comparison is shown, and we plan to address it soon, as noticed above, by adding the action that swaps comparison.

> 2 branches because it makes me to perform one comparison, then switch branches and compare again.

There is no need to checkout the branch to get the reverse comparison, as in fact, it is just a Branch filter. Since 2019.2 IntelliJ supports double-dot log filter as the Branch filter in the Log (git log branch1..branch2), and calling the action opens a log tab filtered by HEAD..targetbranch. So to get a reverse comparison, one could manually edit the filter to be tagretbranch..HEAD, or even HEAD..targetbranch|tagretbranch..HEAD to show the comparison in both ways. It will not be divided into 2 panes though but will have a graph to dedicate commits.

> The old popup dialog also contained a tab showing the actual changed files between one branch and another

Showing the tab was moved to the separate action - Show Diff with Working Tree, next to the Compare with Current in the Branches popup.

Also, it is now possible to call Compare with Current from the context menu to get the comparison of your working tree with ANY commit from the list.

> I'm wondering why in the world JetBrains felt this needed to be "fixed".

The reasons for the change are:

  1. The old dialog lacks features - it is no possible to cherry-pick, revert or merge branches from it, and this is possible with the new view. The new Log-based view allows this.
  2. The old dialog is slow (it takes a long time to load and executes expensive git log calls, especially on bit projects if branches diverge a lot). The new view is based on Git Log functionality and uses log index - so it is fast and cheap.
  3. It opens in a separate frame. This is not very useful if you use the Compare feature to review a branch or cherry-pick something.
  4. Its Files tab actually shows the difference with the working tree and not the branch tip, while the action name states otherwise
  5. It's an old code that requires effort to support and add new features to it, while there is a better engine at the moment.

See also https://youtrack.jetbrains.com/issue/IDEA-207634

Yes, there are issues with the UX here, and the major part is the reverse comparison - https://youtrack.jetbrains.com/issue/IDEA-209664 The UI change is also unexpected and could produce some confusing results (e.g. empty comparison), and we are working on improving this as well.

It would help a lot if exact issues are reported though for the new UI.

Thank you.

-34

>Since 2019.2 IntelliJ supports double-dot log filter 

I checked this video after upgrading: https://youtu.be/33SZL9lIlg0?t=683

but unfortunately, it tells nothing about all these critical (IMO) vcs related features.

It's worth describing, I would never guess how to use it.

I'd appreciate if IntelliJ update this video.

Thanks for your reply and for caring about users.

4

> it tells nothing about all these critical (IMO) vcs related features.

That is true, the changes are very important. I am not sure why the video does not mention it, we'll check and update it, thank you for pointing to this.

The change, however, is described in the Release notes, What's new page and release blog post.

 

-1

My usage of this feature was for reviewing code. My workflow was to switch to the branch I want to review, then from the branch picker do compare with master. This allowed me easily to see the commits that the other branch didn't have, and I could either review the changes commit by commit, or multi-select and review them all. 

I want to be on the branch I'm reviewing so I can see gutter warnings etc. Now my workflow is to manually edit the branch selector thing which is a pain, and I can't easily see if the branch needs rebasing. 

I did find the fact that it used to open a new frame slightly annoying, as occasionally I used to close it by accident with Esc. On balance though I prefer the old method, although if "compare with branch" showed me the commits on the branch I'm on (or there was an easy way to do a "reverse comparison" I could probably get used to it...

 

10

> Showing the tab was moved to the separate action - Show Diff with Working Tree, next to the Compare with Current in the Branches popup.

That is part of the issue: several extra user interactions are now needed to achieve the same result.

While your motivation to get rid of the old pop-up might be valid (some of the points are valid only from your/developers' view, not from the users' view), getting rid of it *before you provide* the means to deliver what the pop-up used to do is just careless.

I believe it would be fair to bring the pop-up dialog back, so you can work on polishing the new way of delivering your goals, so we don't have to wait several iterations for the final solution.

14

I cannot understand the new feature. "Compare with current" opens the git log and shows nothing. It's not clear what this means. And it's not clear what extra steps I must perform to get what I need which is a view of the commits in A that aren't in B together with a list of the commits in B that aren't in A.

18
Avatar
Maksim Ovsyannikov

Please return old version of this feature. It was very useful

19

Me and my colleagues spent a good deal of time exploring the new UI and searching for documentation and new ways to do our everyday work. After this can say

  • The new features are wonderful.
  • They don't replace the old "Compare with Current"

For example, I'm on branch A and I want to see the differences with branch B in terms of commits and diffs

  1. In the Git menu: B > Compare with Current. Nothing is displayed.
  2. In the Branch: filter menu in the VCS Log toolber, Choose "Select..."
  3. Type: "B..HEAD" and Ctrl-Enter

Now I can see the commits in A that aren't in B.

That was really hard to learn (it's hardly intuitive) and even now that I have done it a few times it's hard to do. It's really not easier than using git command line utility.

So I wonder why the old feature was removed? Does it break anything to leave it in?

8

I can't cope. Downgraded to 2019.1

10
Avatar
Levon X Shabagyan -nd

Wow, this is a major regression. Seeing the clear picture: 2 lists of actual commits in each branch on same page was huge part of our daily workflow.

downgrading for now

13

 

Another issue with this change is when you have multiple repositories in your project the log lists commits from all repositories that have branches with the same name, which makes it totally unusable.

 

Manually changing the the path filter is also very cumbersome, most notably there is no option to 'deselect all'.

7

I thought I changed some setting that I didn't see the popup appearing when comparing a branch, but now I read here that this feature has been removed. I liked the very practical view to see what's in one branch and not in the other branch and vice versa. I really miss this user friendly feature. I downgraded to 2019.1 for now. At least give the option or setting to have this popup view back.

6

Please revert this until the new compare is doing what the old did.

The proposed option for reverse comparison does not look like a good solution.

12

I'll be reverting to 2019.1 for the same reason.  

Also, the reverse comparison option is not the same as seeing both at the same time.

This makes me nervous about what other 'improvements' are in the works that are going to mess up my workflow. 

 

 

5

Jetbrains has confirmed that they do not intend to replace this feature. They believe that the git log is sufficient for our needs.

https://youtrack.jetbrains.com/issue/IDEA-207634#focus=streamItem-27-3658136.0-0

Kiril also stated "JetBrains understands that the replacement introduced a couple of usability regressions, and plans to improve new UI to solve these issues, see related tickets." but this is not very honest since said plans are just to make it easier to navigate between different filters in the git log--which is not solving the issues at all.

In other words, nothing will replace the Compare with Current that we are in the habit of using. (Why it had to go remains a mystery.)

Using 2019.1 isn't viable in the long tern and Compare with Current isn't coming back. So we need a strategy. Jetbrains isn't going to provide something like Compare with Current then we need to decide if we will

  1. adapt ourselves and our practices to how Jetbrains wants
  2. find alternatives

I choose 2.

In the last few days I've been learning to use Visual Studio Code. Since I don't know the key bindings, getting started has been slow but its UI for many tasks, including all things git, are superior to IDEA. Plus it's FAST. It looks nicer. It's open source. And it has a vital community of extension authors.

4

Please restore the old UI. Introducing new work flows when the old one is still maintainable and simpler for the average user is terrible UX, in my opinion. IntelliJ is a premium product and charges a premium price, as such, I do not think it is unreasonable to expect the niceties in life. Your competitors are, on average, far cheaper and this was one of your differentiators.

 
Copied and pasted from https://youtrack.jetbrains.com/issue/IDEA-207634#focus=streamItem-27-3658136.0-0 in the hopes someone who can change the person replying here's mind reads it. :) 
5

I just found "compare with current"  works different with 2019.1 which is so uncomfortable ,I can't get the difference between two branches clearly .Can you make it back ? Cause it's so useful ;

5

Please revert old dialog! New feature is useless and inconvenient!

5

Dmitriy Smirnov,

This seams as a great step backwards, I get this might be far faster, using fewer resources and with less steps in between GIT commands/calls and IntelliJ's UI. Also this data is shown in a more streamlined and less intrusive way, but it is extremely terrible for the UX in general regarding this particular (useful) functionality.

  1. This implementation might be faster, but, how much? 10s of milliseconds, 100s of milliseconds, a full second? is neglible against the time it takes people place their cursors in the textbox, type the 2 dots, invert the order to revert compare. In those cases this is orders of magnitude slower.
  2. It is cheaper, but I'd rather waste a small part of my resources on a utility if it is useful (the whole point of an IDE, right? if not I would be using VI, nano or notepad).
  3. If I want the fastest and cheapest GIT tool, I would use it from the bash directly.
  4. All the potential errors that are spared between GIT and IntelliJ are minimal compared to the ones the user could do now that it has to do a harder work when comparing branches, this process has become much more prone to user mistakes. Even more it was my defacto tool to prevent errors by checking before doing an important push or bringing a branch (between several) with unknown content. A couple of great examples: example 1 and example 2
  5. Compare with current does nothing!
  6. Now when tracking changes there is a lot of information crammed in one small place and I have to expand the part showing it to half the screen or more making it more intrusive than a pop up I can move to another screen or just close when I finish using it, nstead of changing to another tab (eg.: local changes) and resizing/dragging a part of the screen.

 

I wont pretend to talk on behalf of all the IntelliJ users, just for myself, though I see that I'm not the only one who dislikes this new behavior.

For me working with GIT/VCS was probably never one of the strong points of IntelliJ, since I consider:

  1. The log view is both hard to understand and visually "ugly" compared to other solutions (GitKraken, GitAhdead, SourceTree/BitBucket, even Eclipse)
  2. Naming of actions or elements sometimes times are terrible (specially when solving conflicts and trying to guess which file version is were)
  3. No way to set remote branches permanently
  4. When tracking changes there is a lot of information crammed in one small place and I have to expand the part showing it to half the screen or more
  5. No dry runs
  6. In the log view, the "Branch" dropdown has no CURRENT option.
  7. ...

So I used to work with IntelliJ, and GitKraken or GitAhdead when I wanted to track changes visually (mainly viewing branches or "log"), then GIT directly in bash for missing features.

But it also had some good/great features.

  1. Partial commits (I would prefer even more granularity, allowing both current partial selection and line by line selection).
  2. Stashing changes and smartcheckout
  3. Interactive rebasing (even if it not always worked OK).
  4. Branch switching with workspace state preservation
  5. Several other features that I probably never even notice (since that is how great features tend to work)
  6. compare with current

And experience was getting better with almost every new IDE version, to the point I uninstalled the GUI GIT manager and started working with just IntelliJ and GIT bash.
Now I reinstalled GitAhead and even installed JetBrains Toolbox so I can switch between IntelliJ 2019.1.4 and 2019.2.

 

I still think IntelliJ is the best IDE for my work, I'm not planning on stop using/paying IntelliJ Ultimate, but as I said, I consider this a huge step backwards on a feature I used a lot and now I have to turn to another tool to do so and that is frustrating.

I feel everything I just wrote wont make JetBrains bring this useful feature back and it will end up being more of a rant than anything else

Cheers,

Luis

12

Please bring back the old functionality for comparing all files between two different branches!  I need that!

Alan

 

7

As others already said: please bring back the previous and way more usable functionality of 2-way branch comparison.

5

Indeed the old "compare with current" view was one of the nicest git features within IDEA. It is really useful to have a way to view the global commit differences between tho branches, specially for code reviewing, merging, backporting and managing different version staging branches.

> Do you usually need both A..B and B..A, or you sometimes need A..B and sometimes B..A?

I usually need the three options, but being able to see both A..B and B..A at the same time is the one i use the most.

> If you need both sets of commits at the same time, do you think it would be useful to show them in a single log view, as two branches (e.g. like the log is possible If you usually need only one set of commits, would it be sufficient for you to have a swap button (as proposed in the description of this issue)?

Being able to switch with a button between both filters would be fine. But i would probably be switching back and forth a lot when reviewing for example an old feature branch that must be rebased, or checking the differences between production and development version, or checking differences between the same branch over two remotes for giving some examples.

> What kind of branches do you usually compare? For example, I usually compare the main development branch (which I have checked out) with a remote feature branch of my colleague, to review their work done in this feature branch. Is your case similar?

I come across many scenarios. Apart from the case you describe, i also have to: check if my current branch has diverged too much from master, check if is safe to rebase two branches together, check which new commits have been merged on master which i do not have in my current branch, check if a remote which is not my tracking branch has commits, check which commits a feature branch adds and if its correctly rebased on master before merging, for naming a few scenarios.

On all that cases, the old view was extremely useful, now i've been having to cope with the current functionality but its cumbersome to be constantly doing "compare with current"-> click filter -> edit and reverse the filter, every time.
Again, a switch button would be useful, but being able to compare both views its incredibly useful.

 

4

bring back the old compare view!

 

after an upgrade from 2019.1.x to 2019.2.x the git compare in PHPStorm is not useable anymore.

i don't want to use another tool for this task but the built-in log X..Y is awful a.f.

 

downgraded now and waiting for a useable interface :-( 

3

Please sign in to leave a comment.