microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
164.94k stars 29.52k forks source link

Add a better git diff and merge view to VS Code like IntelJ, Meld or Kaleidoscope #212736

Closed mathisgauthey closed 6 months ago

mathisgauthey commented 6 months ago

Hey there. Just like #93593 and #37350, I'd like to open the discussion about having a better git diff and merge UI.

Here is the current VS Code diff view :

diff

And here is the current VS Code 3 way merge :

merge-editor-overview

While these are not bad, I am really missing the quality of IntelJ, Meld and Kaleidoscope's take on git diff and merge view. I find it more intuitive and certainly easier to read and use.

IntelJ diff view :

ij_compareFiles

IntelJ merge view :

32250860-c677e4ce-bec0-11e7-82b5-0196d981cc28

Meld diff view :

filediff

Kaleidoscope :

image

What do you think ? Would it be possible to implement such a feature ?

There is currently no extension that allow to do this seamlessly in VS Code directly. SemanticDiff is close, but having another tab type makes for overlap with other git extensions that uses VS Code default view.

hediet commented 6 months ago

Thanks for the feedback!

I am really missing the quality of IntelJ, Meld and Kaleidoscope's take on git diff and merge view. I find it more intuitive and certainly easier to read and use.

Can you elaborate what you find easier to read and use and why? What can you do faster/easier in which tool? Could it be that you are just more used to these tools?

mathisgauthey commented 6 months ago

Thanks for the feedback!

I am really missing the quality of IntelJ, Meld and Kaleidoscope's take on git diff and merge view. I find it more intuitive and certainly easier to read and use.

Can you elaborate what you find easier to read and use and why? What can you do faster/easier in which tool? Could it be that you are just more used to these tools?

Hey there. Actually, I've been using VS Code for years now, but I work with someone using IDEA, and I'm always finding it easier to read changes on IntelJ diff view when we're working together on his setup. I'll talk mainly about the diff view, but it extends to the merge view.

I think I prefer IntelJ view because :

  1. The two panels are still visually connected with flowing blocks that relates to line numbers. (Diff and merge)
  2. I can work on many changes and conflicts at once easily while resolving a 3-way merge conflict.

Diff view

1. Panel connections.

In IntelJ, we have some "flowing" between the two panels. They help to smooth the search for diff between two parts as it shows visually the number of line difference.

image

In IntelJ, we can easily see what was 1 = modified, 2 = deleted, 3 = added, 4 = conflicting :

15a673f0-4d79-470f-99ad-63b33df47d67

With VS Code, there is a "brutal" separation between the two panes that I think reduce the ease of noticing changes :

diff

In addition, I think the UI is less clear about distinguing between what was modified, deleted and conflicting. Maybe it's about the colors.

Merge view

2. Easier whole file merge conflict resolving

IntelJ provides some arrows, like VSCode, to choose between two sides. I know VS Code has a column view, but here again, the overflowing red flows help with noticing which changes are selected across the file :

resolveConflict_dark

IntelJ also resolve non-conflicting changes with a magic wand that allows for faster diff and merge.

With the VS Code approach that you can see below, we can see the line numbers, but our eyes need to move quite permanently between the three view to see which one we want, and which one we applied. We need to look for the bottom panel and see if it's written current or incoming and then look back at which one is which, which makes us lose time.

In addition, this approach forces us to work on one change at a time :

image


Conclusion

I think it's really about having a visually "flowing" view that helps us noticing easily what changed (diff view) and which change we accepted (merge view) with a 3 columns UI that allows to work on more changes at once.

It makes us faster at noticing changes and confirming we're doing what we wanted to do.

Hope this helps !


Sources :

hediet commented 6 months ago

Diff view

In IntelJ, we can easily see what was 1 = modified, 2 = deleted, 3 = added, 4 = conflicting : In addition, I think the UI is less clear about distinguing between what was modified, deleted and conflicting. Maybe it's about the colors.

I'm confused, you are comparing the merge view with the vscode diff view?

It feels like you are discussing creating alignment with spacers (what VS Code/Visual Studio do) or with different scroll speeds (what IntelliJ and other tools do). They have both advantages and disadvantages.

But comparing the diff view with the merge view (which VS Code also has), is unhelpful.

mathisgauthey commented 6 months ago

Diff view

In IntelJ, we can easily see what was 1 = modified, 2 = deleted, 3 = added, 4 = conflicting : In addition, I think the UI is less clear about distinguing between what was modified, deleted and conflicting. Maybe it's about the colors.

I'm confused, you are comparing the merge view with the vscode diff view?

It feels like you are discussing creating alignment with spacers (what VS Code/Visual Studio do) or with different scroll speeds (what IntelliJ and other tools do). They have both advantages and disadvantages.

But comparing the diff view with the merge view (which VS Code also has), is unhelpful.

Hey there ! No I'm not, even if the screenshot with the numbers from IntelJ is from a merge view, the UI color and "flowing" lines between the two panes are similar in their diff view.

What I wanted to showcase is how the simple flowing from multiple lines coming to another set of lines with what was removed, modified or added is really helpful and assist in visualizing faster what changed and how. The different colors are helpful as well.

I find that this part bellow is what is missing in the current diff and merge view from VS Code, and I'm sure it would reduce the time it takes to understand what is different between two commits or what changes we accepted (which side !) from a merge view :

image

hediet commented 6 months ago

Can you post a screenshot how this particular diff would look like in VS Code?

mathisgauthey commented 6 months ago

Can you post a screenshot how this particular diff would look like in VS Code?

Sure, I would probably think of something like that : ij_diff_in_editor

And with some drawings on the current VS Code UX : image

Pardon me for the style that is lacking, I hope I highlighted what I have in mind correctly there.

Basically in the diff view :

And I would also make these changes in the merge view, but only adding the visual flowing to changes that we accepted inside the merge, so that we can visually see easily what, in the result tab, was taken from current and what was taken from incoming.

Thanks for your time in reviewing these observations with me, that's really great ✌️

hediet commented 6 months ago

Can you post a screenshot how this particular diff would look like in VS Code?

I mean can you do a screenshot of VS Code showing the very same diff (same java code)? You are comparing different diffs here.

mathisgauthey commented 6 months ago

Can you post a screenshot how this particular diff would look like in VS Code?

I mean can you do a screenshot of VS Code showing the very same diff (same java code)? You are comparing different diffs here.

Sure thing !

IntelJ IDEA :

image

VS Code :

image

All in all, the points I prefer in IntelJ :

VS Code chose to show delete blocks with the removed lines on the right, it is visual indeed but make us lose time because it creates "dead space" on the right end choice.

It's two different approaches, both have their advantages, but I'd love to be able to find this kind of UI on VS Code someday !

hediet commented 6 months ago

Thanks for the screenshot! Personally, I find the VS Code view much easier to process (also because of the moved code detection). I guess it is a matter of personal taste in the end.

I'm going to close this issue due to its unspecific title and unclear actionables, but feel free to create a new issue specifically for "Add option to hide spacers in diff editor, use scroll-alignment instead (as in IntelliJ)" (though such feature request may exist already).

mathisgauthey commented 6 months ago

Thanks for the screenshot! Personally, I find the VS Code view much easier to process (also because of the moved code detection). I guess it is a matter of personal taste in the end.

I'm going to close this issue due to its unspecific title and unclear actionables, but feel free to create a new issue specifically for "Add option to hide spacers in diff editor, use scroll-alignment instead (as in IntelliJ)" (though such feature request may exist already).

Fine by me, thanks for listening to my point ✌️

guilhermetod commented 4 months ago

I suggest this is reconsidered, I am trying Webstorm and I still prefer VS Code, but the diff editor is much better. The conclusion here might be to being used to VS Code, but I would guess blind tests would lead to majority preferring Webstorm in favor of VS Code diff.