Git dedicated panel and integration

[slemeur]

Goal

The current Eclipse Che version is providing a Git plugin with many of features but the overall experience is tedious for users. Simple actions are needing a lot of interactions and the user flow have been made complex. The current git integration is also lacking of feedbacks to show to the user the changes that have been made.

The goal of this epic is to rethink the Git experience in order to improve the developer efficiency and provide integrated features (in the editor and in the explorer).

We'll provide a new Git panel, which will be displayed in the left area. This panel will allow the user to do the most common Git actions more easily and will progressively replace certain of the features currently implemented in the git plugin.

Linked issues and discussions

• Improve Git workflow #1605
• Improve Git commit window #3614
• Git preferences for command line #4969
• Support git pull --rebase #3415
• Support git push -f #3416
• Show current git branch in the IDE #5335
• Mark with colour Git changed files in project explorer #5339
• Implement coloured marks in editor to show Git changed lines #5340

Subtasks

• Add git panel to display local changes Add git panel to display local changes #6361
• Synchronize list of repositories and the list of local changes Synchronize list of repositories and the list of local changes #6608
• Apply new styles to the widget displaying local changes Apply new styles to the widget displaying local changes #6645
• Port git dedicated panel to che6 Port git dedicated panel to che6 #7022
• Git commit window tree files view selection model confused
  Git commit window tree files view selection model confused #6255
• Ability to commit files in git dedicated panel Ability to commit files in git dedicated panel #7085
• Hide panel if there is no git projects

Details

Git Panel:
We'll introduce a new git panel which is composed of 3 main areas:

• Repositories: to select the project to interact with
• History: to select local/remote branches, browse previous changes and interact with the remote repo to fetch, pull or push
• Local: to see the changes and execute a commit.

Commented:

Commit Options:
When doing a commit, we'll provide certain options to the user so that it will be easier to configure the commit parameters. We'll provide:

• Ability to amend the latest commit
• Sign off the commit (taken from git preferences defined in the workspace)
• Automatically push the changes to the remote repo

The git commit options will be valid only to the commit currently in progress.

List of changes:
The list of changes will provide two view options: flat list or tree view.
The list of changes can also be sorted by different options.
The list of changes will use icons to show the different type of changes, those icons are getting a color which will be used in the project explorer and in the editor consistently.

Flat list:

Tree view:

List display options:

It will also be possible to do a right click on the files in the list of changes to remove a file, add to gitignore or reset to an certain version.

Diff view:
We'll display in the editor area the side to side view to compare the changes.
TBD: Later we will add ability to stage the changes, discard the changes from this view too.

Pull view:
Clicking on Pull or Push will open dedicate popups.

The pull view is going to show more options and allow to rebase instead of merging.

(Note: design on popups is not final and might change before final version.)

Editor and Explorer Integration:
We will also integrate Git inside of the basic elements of the IDE, such as the project explorer and the editor. The goal is to show to the user on which branch he is currently working on and also the various changes he has in progress.
The colors used, will be consistent with the Git Panel.

[iamslite]

Seems generally good. Is the intention that the existing context menu entries remain on the project explorer as a way to selectively modify the index?

Presumably there would be two sets of colours/some iconography to distinguish between say, a new file and a new file which has been added to the index ready to commit, and similarly with a modified file.

(Incidently, your TBD on the diff view is one of the reasons why I love emacs as an IDE ;-)

The other questions are an idea of how long it is likely to take and when we might start seeing it. Partly because if this is going to take a while then can we look at getting something like #5081 in as a short term workaround (which this would otherwise obsolete.)

[slemeur]

@iamslite Thanks for your feedback.

Is the intention that the existing context menu entries remain on the project explorer as a way to selectively modify the index?

Yes for now, no plan to change that behaviour from the project explorer. But you could use the list of changes to select the files to be added to the index or added to the gitignore.

The 'TDB' item, for the ability to stage lines or chunk, will be addressed, we agreed that it is an important point. I would probably

For now this issue is not yet estimated - hopefully, we'll have important parts of the specification done with Che 6. But until we have that in place - we will have the improvement from #5081, which could be seen as a preliminary work.

[wernight]

Using the entire screen is a neat idea. Visually one should see first:

• Commit title
• Commit button (probably with a way to synchronize, i.e. pull --rebase && push)

In that UI the accent is on the diff. The commit button is so tiny. It's not event visually clear what is going to be committed visually speaking (I'm not comparing to existing). It's mostly about proportions and visual grouping. GitKraken is known for it's pretty good UI which is similar to that concept but visually more clear: https://youtu.be/9YCO-3_MApI the large commit button is on the bottom right and visually you go from top to bottom.

I'd still advocate to have more a GitHub Desktop UI which is simplest IMO and yet also similar.

It's of cours a bit difficult to give feedbacks on a rather novel UI without trying it.

A left panel is generally a way to access things and open them. I'm wondering how it may mess up things. Git is usually a way to access and modify and shared history. It'd not mix current editing with history. These are like two different things. So as long as it's clear that there is a Git state and a edit state, I think that's fine.

[neilmackenzie]

It would be nice if it is easy to configure which diff viewer is used. I am curently looking into making a graphical diff viewer for EMF models using EMFCompare to provide a similar experience in che to comparing models in eclipse desktop IDE.

[vinokurig]

I see this panel like 'Express Git panel' to perform most popular Git operations directly near editor. I think we should keep existing Git functionality (in menu and context menu) as a base Git functions, and make this panel as additional place for most common Git operations.

1. According to description all actions in the panel are related to selected project in the repositories part. I think this might be confusing for user, so I propose to move the panel to the right to see both project explorer panel and this panel, so user will have an ability to select project from project explorer.
2. Select local and remote branch section is confusing for me. What is the purpose of of this secion? If this section is needed to select branch to push than I think we don't need it in this panel because this is present in advanced Git operations (from menu). Express Git push should be setup to current branch.
3. I think Diff view should be opened in a separate window (like now), not in the editor. We can add go to next/previous changed file functionality to existing window.
4. I think Commit button shold have a lable (Commit).

[slemeur]

@vinokurig Thanks for your review and your feedbacks.

1. If I understand you properly, you want 2 panels. If so, it is not the experience that we are looking for as it's going to take more space. I can understand that today, git actions and menus are bound to the current selection in the project explorer. But, when the git panel will be active, we will need to bind the git actions/menus from the repository selected in the "repository section".

2. With this panel we want to allow the main git operations without having to navigate into menus and having popups. Few other tools are handling it this way and the experience is very convenient.

3. We want to minimize the number of popups used by the product. We also want the user to be able to benefit from the layout flexibility that the editor is providing: open multiple diff, split horizontally/vertically.

4. Yes agreed. I'll update that in the mockup.

[wernight]

Do you have a working demo somewhere or is it only a concept so far?

[tolusha]

@slemeur
Hello.

My thoughts concerning git panels.

Local: to see the changes

I am afraid but the size of the panel might be too narrow to see the full path of the modified file.
So, users will be irritated and will have to do manipulation with the mouse to change the width of the panel. From this point of view I would like to have this panel at the bottom of the IDE.

To commit, to push, to pull

If some action doesn't require interaction with other IDE windows then I prefer to see the popup window at the middle of the screen. Because it is the location when my vision usually is directed to. It is not convenient to change that angle especially having wide screens.

[slemeur]

@wernight : We are starting the work on this epic. So for now we just have the spec here.

@tolusha :
On first point: We can handle the display of the file path, by truncating and using hover to display the full path. After that... it's really a question of personal preference. Ideally, user should be able to move the panel where he wants.

On second item: I can understand that point but I really believe that the panel will provide a better experience. Having the panel side to side with the editor allows few use cases that are not possible with our popups. For example:

• when you are reviewing your unstagged changes before you commit, you can open the file, check the changes and edit directly, you do not loose the context (instead of opening popup, closing it, then finding the file in the project explorer).
  We will not handle all the Git features from the panel - we will keep the current popups we have, but for the most used features, the panel will allow faster actions.

You can test what it is like to have git integrated as a left-panel by experiencing VSCode.

[tolusha]

@slemeur

On first point:

It is not convenient :)
User has to move a mouse to see a hover. Is it better to show a full path immediately? Especially knowing that the most wanted entry (file name) located at the very end. Users always will suffer from that.

when you are reviewing your unstagged changes before you commit, you can open the file, check the changes and edit directly, you do not loose the context (instead of opening popup, closing it, then finding the file in the project explorer).

It is what I wanted to say. If some interaction requires editor or other panels then I prefer panel.
But in case of pull/push may be some others I prefer popup window.

You can test what it is like to have git integrated as a left-panel by experiencing VSCode.

I don't think it is good experience.
They also put debug panel on the left side, but for me it looks completely unacceptable.

[vinokurig]

+1 for popup window. Adding navigation to previous / next diff functionality to current diff window will make review changed files much easier.

[sunix]

-1 popup window because it forces users to close the popup to check other things in other panel or editor.

[slemeur]

@tolusha :

On first point: We can handle the display of the file path, by truncating and using hover to display the full path. After that... it's really a question of personal preference. Ideally, user should be able to move the panel where he wants.

It is not convenient :)
User has to move a mouse to see a hover. Is it better to show a full path immediately? Especially knowing that the most wanted entry (file name) located at the very end. Users always will suffer from that.

When doing a git operations, I don't think the full path needs to be displayed all the time. It can be displayed partially and the length adapted to the width of the panel. User will have the choice between the list view or the tree view. If he choose the tree view, he'll probably resize the panel (similarly to what he would do with the project explorer). If he choose the list view, he wants a more compact view - then the full path is not needed.
See how SourceTree and VSCode are handling that. We don't need something more complex.

VSCode:

SourceTree:

It is what I wanted to say. If some interaction requires editor or other panels then I prefer panel.
But in case of pull/push may be some others I prefer popup window.

Yes, we will continue to use popups we have in order to do pull/push operations, as in the mockups.

I don't think it is good experience.
They also put debug panel on the left side, but for me it looks completely unacceptable.

It is a question of personal taste, but using a vertical tab for quick git interaction is something that other tools are doing and which is positively received by users. (VSCode, Atom)

@vinokurig : we can add that later to the review tab. but -1 for popup, because interactions with popups are blocking the user. When a review popup is opened, the user can't change the file without closing the review popup so he can't quickly review multiple files. Side note, by using a review tab, that would allow to compare different files at the same time.

[vinokurig]

@slemeur

When a review popup is opened, the user can't change the file without closing the review popup so he can't quickly review multiple files.

Actually it is possible to edit files and save changes directly in the diff window. Listing multiple files in the diff window is not a problem to implement.

[ashumilova]

+1 on using popups to confirm user actions, notifications/alerts (errors, warnings) and -1 for using popup for diff, as far as now it:

• looks cumbersome
• not friendly to lower resolution devices (laptops as well)
• brings to nested popups
  

[gazarenkov]

I do not see any problems with popups. It looks quite reasonable in IntelliJ for example (btw why you think they leave it in popup? My guess is that they do not want to overload main view making it more confusing) and since by the UI concept we are closer to it I would leave it instead of struggling with other, especially taking into account that we probably will move to Monaco soon.
So why spend time on it instead of improving current one. Users definitely can live with it.
Maybe the only one reason sounds more serious - "not friendly to lower resolution devices (laptops as well)" - @ashumilova could you please elaborate a bit?

[ashumilova]

The result of lower resolution is attached in previous comment, the content of the popup with diff doesn't fit the page, thus part of it along with controls is not accessed.

[tolusha]

@slemeur
As a user, I hate resizing panels especially using a splitter.

[gazarenkov]

@ashumilova but can not it be fixed with proper styles?

[vinokurig]

I think that the problem with low resolution and diff window can be solved by implementing 'full screen mode' or something like that in that popup.

[mmorhun]

The result of lower resolution is attached in previous comment, the content of the popup with diff doesn't fit the page, thus part of it along with controls is not accessed.

That's problem of all big popups, not diff only. As a workaround try to change zoom level.

I think, it will be good (and enough for now) to have an ability to maximize the diff widget. It would be matter of a user to use it as is for quick sight or maximized for long reviewing and edition.

[ashumilova]

In IDE the size of popups is defined on implementation stage and fixed. For such cases - whether need to have dynamic resizing or manually by user or full screen mode.

[slemeur]

First, we should try to avoid confusion when discussing, I see a lot of mixes between UI (= styles) and UX (= end user experience). Sometime, fixing styles helps the end user experience, and sometime it is not enough.

It will be difficult to know why in IntelliJ they are keeping their review mode in popups. From what I see here, the git integration in IntelliJ was built around 2009. IntelliJ is very cool and powerful, but it does not have to be taken as the only way to go for everything we are building. You are using it, you are used to it. I understand that.
If you take this mockup, you'll get that we targeting a different experience than IntelliJ - for both UI (styles + colors) + UX (layout and interactions).

I don't think the diff review in a popup is a great end-user experience for the following reasons:
1- Diff on a file should be considered as a different editor mode. As user, I can see the changes in my file's editor (in the gutter), I should be able to switch into diff mode without having a new view that is breaking my flow.
2- I should be able to check multiple changes at the same time. A popup is a creating a modal UX, which is perfect for a single action - but when you want to see multiple things at a single time, you can't.
3- By using a popup, we artificially create a 2nd way to edit files. It is not consistent as it is used in only one place. The problems with that are multiples: first user might even miss that he can edit from the popup, second the popup needs a lot of hooks in order to handle editing behaviours (like the screenshot from @ashumilova where it displays a 2 level of popup to confirm changes). By using a classical editor, you avoid those problems.

I actually think that integrating the review popup in an editor-tab (or as an editor mode) would be simpler than trying to make the popup more usable:

• I see mentions about the fullscreen mode, we already have that in place with the editor's tab - you can just double-click on the tab to get it maximized. The UX for that is naturally handled and we don't need to recreate another experience
• The save experience is already in place
• Don't need to implement any dynamic resizing
• Don't need to implement the ability to "move" the popup in the IDE

So for me, moving the diff review popup to be in an editor tab will benefit to the end-user and the implementation effort.

[gazarenkov]

Well, I am quite an old-school guy so I mostly consider UI as an " interactions between humans and machines" and styles as... styles :) .

I did not say I against tab inside Editor panel in this particular case (in contrast to some else) since, yes, it is kinda other view of file.
What I am saying is that popup is reasonable and useable as well, new tab is reasonable too and as I said looks logically but I would not like to pay too big price for it since to me it does not look that sufficient for experience. And it is not for free for sure, at least you have to think of how to place specific for diff control elements between "standard" ones and make it clear for user, which is not a problem for popup since it is standalone (modal) window with own control elements.
I do not understand the problem with modality you mentioned since I can not imagine what other changes you may want to check simultaneously.
For the alternative editor - yes but I would not make diff view as full-featured editor (unlike IntelliJ AFAIK) only to view and merge.
So, to me, it depends on estimation, if nothing or small - why not, otherwise - do not think it is a good time to reimplement.

[sunix]

Personally, every time I have a popup, I start to fill some information, then I want to check something in the IDE, I close the popup window and do my checks and reopen the popup window and refill the information ... etc ... Finally I don't use the GUI because it's not usable for me. To me, pop up window should only be about yes/no question or confirmation but if you start to have a lot of interactions it is not usable at all. The mockup here is very good to me and we'll make things way better than IntelliJ.

[gazarenkov]

Yes, that's exactly my question: what kind of information you need to check in this particular case to understand how important it is to rework it to tab (I am not debating popup vs tab)
I.e. I open diff with 2 files with purpose of compare and probably merge something. I usually do not edit files just here etc. So, yes, I open it to perform some limited set of operations and I suppose all needed info is here (more like advanced "yes/no" action).
What do you do with it in addition?

[slemeur]

@gazarenkov This epic is in the scope of Che 6 since we framed out the requirements for that new version. The epic has been defined accordingly with the business needs, competitive study and user feedbacks. The goal of the epic is stated in the description.

I'm clearly opened to create phases for the implementation of the epic (this has been asked to @vkuznyetsov BTW) - but I'm expecting to deliver the Git panel with commit and push capability to our end-user.

[JamesDrummond]

@slemeur Are you going to provide the recursive git option?

[slemeur]

Closing as won't fix for the time being - This epic will need to be recreated for the new generation Che ide. (#8266)