Move Git history view to scm-extra package

[westbury]

What it does

The SCM view currently supports different SCM types through VSCode APIs. However the History view supports Git only. This PR refactors the history view, splitting apart the Git specific code from the history view. This allows a single history view to be shown that tracks the selected repository regardless of whether the repository is a Git repository or a repository from another source manager type such as Mercurial.

This PR moves GitHistoryWidget to ScmHistoryWidget in the SCM package. GitNavigableListWidget and other dependencies have also been moved.

The VSCode does not have API to support history. Therefore we define our own API. I could have implemented this in a similar way to the AmendSupport interface, where the provider provides an implementation. However I decided instead to create a child container for each SCM type, so one child container for Git, one for Mercurial etc. The history support implementations are bound in these containers. The containers containing the repository options are now child containers to these. This approach gives flexibility when adding extra SCM types, or extra an extra interface, or an implementation of an interface for a particular SCM type. So, for example, someone could add support for SVN but not implement the History interface. Someone else could add an extension that implements the History Support interface for SVN and bind it in the SVN child container.

How to test

This PR should be tested to ensure that it works with Git repositories exactly as before. The only differences one should notice is that the view label has been changed from 'SCM' and 'Git History' to 'Source Control' and 'Source History'. The label change was preferred by our UX team but if there are reasons for using the same label as VSCode then I can change it back and we will override it in our application.

Review checklist

• [x ] as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[akosyakov]

Does it make sense to move Git History to SCM? There are already VS Code extensions providing git history. They should be used. cc @svenefftinge

[westbury]

There are already VS Code extensions providing git history. They should be used

Are you saying the current Git History should be removed completely from the Theia code base in favor of using VS Code extensions?

Unless I am missing something, the VS Code extensions are specific to a single SCM type. Extensions written for Git won't work with Mercurial etc. Our requirement is that the history view shows history for different SCM types, switching between a Git and Mercurial repository in the same way that the current SCM view switches seamlessly between Git and Mercurial repositories.

[akosyakov]

Are you saying the current Git History should be removed completely from the Theia code base in favor of using VS Code extensions?

Not remove, I don't think it makes sense to have it in the SCM extension, since each vscode extension will bring own history implementation.

Unless I am missing something, the VS Code extensions are specific to a single SCM type. Extensions written for Git won't work with Mercurial etc. Our requirement is that the history view shows history for different SCM types, switching between a Git and Mercurial repository in the same way that the current SCM view switches seamlessly between Git and Mercurial repositories.

Yes, but each VS Code extension can provide a tree view or a webview to implement history specific to a SCM type.

I would prefer that we discuss it on dev meeting when Sven is back. Unfortunately in 2 weeks after EclipseCon. It is not clear to me how we should move forward.

[akosyakov]

@westbury I've chatted with @svenefftinge about it. Let's keep @theia/scm with minimal code required both for Theia and VS Code extensions, but add a new package @theia/scm-extra which contains reusable widgets for Theia extensions. Would it work for you?

Also wonder whether you are interested into using @theia/git if the rest of community moves to use VS Code extension? The question is whether we can delete it after deprecation or we have to move it to own repo and someone has to maintain it.

[akosyakov]

Looking at the PR: We should test that the layout with git history view created by old Theia is still can be opened. Theia has the layout migration contribution:

theia/packages/core/src/browser/shell/shell-layout-restorer.ts

Line 88 in f255f5a

export interface ApplicationShellLayoutMigration {

We should add a new one if the layout restoration breaks. Please look at other implementations as examples.

[westbury]

add a new package @theia/scm-extra which contains reusable widgets for Theia extensions. Would it work for you?

Yes, moving into scm-extra would certainly work for us. It makes sense that the scm package is the minimal needed to support the vscode SCM extensions. The 'amend' support could also be moved, perhaps by allowing Theia extensions to contribute sections to be bottom of the SCM view.

We will obviously need some discussions here on what we do if the rest of the community abandon the Theia git extension. Note the following concerns:

• vscode extensions do not have full coverage. For example there is no Mercurial extension that has anything equivalent to the history view, and this would be a loss of feature for us because Mbed Studio currently shows Mercurial history in Theia's history view by using the very flexible Inversify framework.

• vscode extensions do not provide a consistent UI. Most of our users are not avid Mercurial users. If they are using a library from a Mercurial repository then they would expect to be able to access and maintain it through the same UI as Git as far as possible. vscode does this very well for the SCM view but then leaves each SCM extension to itself for anything outside the SCM view.

• The Inversify framework is very powerful. It would be a big loss to abandon that and move to vscode extensions. Extenders will no longer be able to rebind to customize UI provided by a vscode extension.

cc: @mcgordonite @thegecko @arekzaluski

[westbury]

I would prefer that we discuss it on dev meeting

Yes, let's discuss it tomorrow. I'll be on the dev meeting.

[akosyakov]

ok, added to the agenda: https://github.com/eclipse-theia/theia/wiki/Dev-Meetings#agenda-2019-10-29

[benoitf]

on Red Hat side, we're using only VS Code scm (we've removed all extensions from 'our' Theia that have VS Code extensions counterpart)

[westbury]

I have now

• moved it to a new scm-extra package
• added an upgrader so the history view is restored in the layout
• rebased on top of the theming changes

Unfortunately there is now a failure in the integration test. This fails for me locally even on master. Many of the views seems to randomly fail to open and close.

[westbury]

The integration tests now pass on CI again, so this is now ready for review.

@akosyakov We appreciate your considering this PR because being limited to what we get from VS Code extensions really does not work for us. I understand this may move to a separate repository if you remove native Git extension.

[federicobozzini]

I'm not sure why I'm seeing this difference in behavior, maybe just a cache issue.

There also seems an issue with the git history.

In some cases when in the Git history panel a commit is expanded and a file is clicked to see its changes, it the file is opened without showing its name in the monaco navigator.

I need to add that this behavior is also present in the master branch.

[westbury]

Thanks @federicobozzini for testing this. I don't think either of the two issues are problems on the branch.

In an empty workspace add a folder a with a subfolder b. Initialize b to be a git repository. b is now the selected repository of the workspace (as you can see from the left-bottom selector). Now initialize a to be a repository. If you restart Theia, on master b remains the default repository, while on @westbury branch a is selected.

I can't reproduce this. If I stop Theia while b is the selected repository, then git init a, then restart Theia, I see b selected but a now added to the list. Same if I don't stop Theia. It could be a cache issue as you say if somehow the selection was cleared so the outer repository would be selected as the first in the list.

In some cases when in the Git history panel a commit is expanded and a file is clicked to see its changes, it the file is opened without showing its name in the monaco navigator.

This one is caused by the label provider. It can be fixed by changing the following line to return 'undefined' (now that that is allowed courtesy of 11be0c0)

theia/examples/api-samples/src/browser/sample-dynamic-label-provider-contribution.ts

Line 78 in 46a2d51

return super.getName(uri);

However the fix to the label provider is bigger than that so needs to happen under a separate PR. The bug is on the master branch.

[akosyakov]

@federicobozzini but generally It looks good to you?

[federicobozzini]

I've done another round of testing and I've found only one minor issue. When focusing on an element in the history panel, a blue border appears around some elements in the history.

It looks like it's caused by some css rules that are still applied using the .theia-git selector, while instead the new .theia-scm should be used.

Except for that, I can't see any meaningful difference.

[akosyakov]

thanks, blue border should be fixed before merging

I test now too.

[thegecko]

thanks, blue border should be fixed before merging

Agreed, this will be addressed on Monday

[akosyakov]

Please have a look at #6381 (comment) too. This API is not used in the scm extension.

I did some testing and could not find anything completely broken. Only thing which bothered me how we name Git History now. It is Source History, maybe File History or File Timeline is better? cc @svenefftinge

@jbicker @kittaakos maybe you can test a bit too, git view, diff and history in particularly?

[akosyakov]

Discussed with @svenefftinge to name it History without Source.

[westbury]

I've made the following changes:

1. 'Source History' -> 'History'
2. The blue outline has been removed. The focus css was moved from theia-git to theia-scm. I have checked it is not needed in theia-git so it is a move not a copy.
   3 Removed the extraneous 'get' function declaration from ScmProvider.
   I believe that addresses all the outstanding comments.

[thegecko]

Thanks @westbury

@federicobozzini could you re-test?

[federicobozzini]

Re-tested. The issue I pointed out is not present anymore.

[akosyakov]

@thegecko @westbury Is it very urgent? Could we await release and land it on Friday? @marcdumais-work release is this Thursday correct?

if is is urgent, i'm fine with merging.

[marcdumais-work]

release is this Thursday correct?

Correct

[thegecko]

Could we await release and land it on Friday?

No rush, don't want to risk de-stabilising before a release :)

[westbury]

I have rebased onto the 0.16.0 release. There were no conflicts other than the usual changelog and version numbers. However there is a test failure which appeared. I have seen this test failure before but it went away after a rebase. It was intermittent in that it appeared when rebasing then went away with the next rebase.

I have fixed the tests by making a couple of changes in editor-decoration-style.ts and git-repository-provider.spec.ts. The offending code in editor-decoration-style was never executed when the branch is in a passing state.

[akosyakov]

looks good to me

[vince-fugnitto]

In the future (once it is stabilized), we might benefit from using the new timeline api with the contributed git commit history view:

https://github.com/microsoft/vscode-docs/blob/ba22868d9ac135dd47265d8f6c2e6d160a2b142a/release-notes/v1_42.md#timeline-view

[akosyakov]

@vince-fugnitto could you file an issue we have to implement a widget in the scm extension which supports such API

[vince-fugnitto]

@vince-fugnitto could you file an issue we have to implement a widget in the scm extension which supports such API

I believe it is a proposed API still, and looking at the view it seems to be for the Explorer?

[akosyakov]

@vince-fugnitto agreed maybe we have a look at it in half a year