giseldo/neodataset huggingface dataset:
Spike: Implement remote repositories similar to GitHub

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "feature" label:

- https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues?label_name%5B%5D=feature

and verify the issue you're about to submit isn't a duplicate.
--->

### Problem to solve

<!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." -->
Microsoft recently [introduced](https://code.visualstudio.com/blogs/2021/06/10/remote-repositories) a new RemoteHub extension which made it possible to view and edit GitHub repositories without cloning them. It will be a very good idea to implement the same functionality in this extension in regard to GitLab.


### Proposal

<!-- How are we going to solve the problem? -->
There is a [documentation](https://github.com/microsoft/vscode/wiki/Virtual-Workspaces) about the underlying Virtual Workspaces API which is used to implement that extension. Unfortunately, the original extension is not open source, but there is an [issue](https://github.com/microsoft/vscode/issues/123115) about Virtual Workspaces API proposals and questions.

### Further details

<!-- Include examples, use cases, benefits, goals, or any other details that will help us understand the problem better. -->

### Links / references

Story points: 2.0
Context menu shows when trying to add an MR comment + duplicated comments

### Summary

Opening MR item multiple times in different places in the side-panel registers multiple comment controllers. That results in UX that lets the user choose which controller to use (context menu) and it will cause every MR diff comment to show twice.

![Screenshot_2021-06-15_at_15_30_27](/uploads/458a8c2e1aa8661e8ebe229833601a5a/Screenshot_2021-06-15_at_15_30_27.png)

![double-comment-controller-2](/uploads/4f2f3f1f6697e47cd0b5bbba324e0902/double-comment-controller-2.mp4)

### Steps to reproduce

1. Click on an MR in the extension side panel in multiple places:
  - For example, you open "Merge requests assigned to me" and "All project merge requests", and open the same MR in both views
1. Open one changed file in this MR
1. Try to add a comment - you'll see a context menu
1. If the MR contains comments on the MR diff, you'll see them twice.

### What is the current *bug* behavior?

- You have to choose which controller to use from the context menu
- You see comments on the diff twice

![Screenshot_2021-06-15_at_13_35_06](/uploads/1d895af1d4fedc9edd9246baa499a87d/Screenshot_2021-06-15_at_13_35_06.png)

### What is the expected *correct* behavior?

- A new comment thread should open as usual.
- Each comment shows only once

### Workaround for adding comments

Choosing  one of the options will work fine:

![choosing-controller](/uploads/782a11432e74d9ff5762327e39570265/choosing-controller.gif)

### Possible fixes

We must ensure that only one commenting controller gets initialized.

Story points: 1.0
Add "View as Tree" option

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "feature" label:

- https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues?label_name%5B%5D=feature

and verify the issue you're about to submit isn't a duplicate.
--->

### Problem to solve

Right now the extension shows the changes of an MR as flat list. Each element in the list has the path next to it. This works pretty well but for bigger mono repos it is hard to review. VSCode itself support the "View as Tree" option in the git diff view. This will show the changes within it's directories 

![image](/uploads/8ed7bada1003b5887270555457f873c5/image.png)

GitLab support this as well :wink: 

### Proposal

Add a button (View as Tree) similar to VSCode diff view to switch between this 2 variants. This would make reviewing in some cases much easier.

### Further details

Checkout the git diff view of VSCode with some sub directories to see the effect in action.

### Links / references

Story points: 2.0
MR Review: indicate which changed files have MR discussions

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "feature" label:

- https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues?label_name%5B%5D=feature

and verify the issue you're about to submit isn't a duplicate.
--->

### Problem to solve

When I'm reviewing MR's I don't know which files have MR discussions before I show the diff and scroll to the comment.

### Proposal

I propose the same solution as GitHub Pull Request extension uses. Add a text bubble emoji decoration the same way we add decoration for the type of change.

![_Extension_Development_Host__-_webview_controller_js___gitlab-vscode-extension-TEST_and_extension_js___gitlab-vscode-extension](/uploads/6841da534bdc198ad2e900b47d75fd33/_Extension_Development_Host__-_webview_controller_js___gitlab-vscode-extension-TEST_and_extension_js___gitlab-vscode-extension.png)

### Further details

#### GitHub Pull Request Screenshot

![Getting_Started___github-test-repository](/uploads/7352c18bfca0eb1d41c0e29fdfe4f6d2/Getting_Started___github-test-repository.png)

### Links / references

I created a POC, the change seems fairly simple https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/commits/commenting-decorator-poc

/cc @phikai @pedroms

Story points: 2.0
MR Review: improve UX when extension fails to create new comment

### Problem to solve

We implemented creating comments on MR diff in https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/342.

The happy-path scenario works well, but when the comment fails to send (network failure, GitLab API unavailable) the UX is not great. We show the user an error message and store the comment text in extension logs, but we don't offer an easy way to retry sending the comment. Each failure has to be followed by copy-pasting the comment text from logs and trying again.


### Proposal

We should handle the failure similarly to the GitHub Pull Request extension. We should create a new type of comment (failed comment) which would have a button to retry.

1. Creating comment fails
1. Extension creates a failed comment and puts it into the diff discussion
1. The failed comment has a "Retry" button which lets users try to resend it

### Current UX

![new-comment-error](/uploads/74717853ba06403865b21dda8b03a57a/new-comment-error.mp4)

Story points: 2.0
Inserting snippets is broken for newly created snippets

### Summary

Newly created snippets can't be inserted. Applies only to `gitlab.com` (and soon to `14.0`)

This issue is caused by GitLab switching to `main` branch name.

### Steps to reproduce

1. Create a project snippet
1. Try to insert it with `GitLab: Insert snippet` command

### What is the current *bug* behavior?

When calling API to get the snippet blob, you get 404

### What is the expected *correct* behavior?

inserting the snippet

### Relevant logs and/or screenshots

The extension makes a call like:

```sh
curl -H "PRIVATE-TOKEN: $TOKEN" "https://gitlab.com/api/v4/projects/20486274/snippets/2128747/files/master/blah.patch/raw"
```

(notice the **master** branch in the request)

We should instead make call to 

```sh
curl -H "PRIVATE-TOKEN: $TOKEN" "https://gitlab.com/api/v4/projects/20486274/snippets/2128747/files/main/blah.patch/raw" 
```

(notice the **main** branch in the request)

Story points: 1.0
create snippet from git patch and apply patch stored in a snippet

### Problem to solve

When I review MR, sometimes I want to suggest changes that span multiple lines in multiple files and the "suggestions" GitLab feature is not powerful enough for that.

Then I result in creating the changes locally, running `git diff > suggestions.patch` and including this patch to one of my MR comments.

### Proposal

Introduce two new commands: `Create patch snippet` and `Apply patch snippet`.

![poc video](https://gitlab.com/gitlab-org/gitlab-vscode-extension/uploads/93f89519e56c165c63b08d2e6658b9cb/snippet-patch-poc.mp4)

#### `Create patch snippet`

1. run the command
1. VS Code asks for the patch name and visibility
1. VS Code runs `git diff` to get the patch
1. project snippet with name `patch: <name submitted by the user>` is created

#### `Apply patch snippet`

1. run the command
1. VS Code shows a list of all snippets with `patch: ` name prefix
1. select one patch
1. VS Code runs `git apply` to apply the patch

### Further details


### Links / references

/cc @phikai

Story points: 2.0
Add support to open local file during MR reviews (file diff view)

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "feature" label:

- https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues?label_name%5B%5D=feature

and verify the issue you're about to submit isn't a duplicate.
--->

### Problem to solve

When reviewing a merge request sometimes it's better to have better insights on the file like the file path, checkout neighboring files and folder etc.. and sometimes we might even need to open the file in the local to make a small change to see if it would workout or not.


### Proposal

Utilize a native feature in VScode to open a diff view while knowing the local path of that file, that will enable few features in VScode like (open file) button, the breadcrump and will allow some of "gitlens" extension features get activated

### Further details

<!-- Include examples, use cases, benefits, goals, or any other details that will help us understand the problem better. -->
Current GitLab Workflow MR file diff view actions:
![GL](/uploads/191f1af9864a2981ca6bb5d726375a23/GL.png)

Assumed to be an achievable behavior (Notice the breadcrumb and the "open file" action on the left): 
![GH](/uploads/2d0fa14bfa6f3f4cecba92f63ff1c7c8/GH.png)

I'm aware that the file path is already available on hover, but that doesn't exactly give the features of a breadcrumb found in VScode.
![GL_path](/uploads/af995896ee05058dc535cc7d89e75c8c/GL_path.png)

Some of the features activated by gitlens when a local file with history is diffed (Git blame, refs navigation):
![GH_gitlens](/uploads/adc8a3abe931a22b154dc605df16d849/GH_gitlens.png)
 
### Links / references
(I've no knowledge of the VScode APIs)

Story points: 1.0
Inserting snippet into user's snippets fails (multi-repository workspaces)



### Summary

When a user tries to add a snippet to their user snippets (rather than project snippets) the command fails.

### Steps to reproduce

User tries to add a snippet to their user snippets (rather than project snippets):

1. Open folder containing multiple repositories
2. Open file from one of the repositories
3. Trigger the `GitLab: Create snippet` command
4. Select `User's Snippets` in the project selection
5. See the command fail

### Possible fixes

I added all caps comments to the following snippet from [create_snippet.js](https://gitlab.com/gitlab-org/gitlab-vscode-extension/blob/ca514167e28766b74c24faba255802920468ce05/src/commands/create_snippet.js#L66-111)

```ts
async function createSnippet() {
  const editor = vscode.window.activeTextEditor;
  let repositoryRoot = null;
  let project = null;

  if (editor) {
    const repository = gitExtensionWrapper.getActiveRepository();
    repositoryRoot = repository && repository.rootFsPath;
    try {
      project = repository && (await repository.getProject());
    } catch (e) {
      logError(e);
    }

    // FIXME: the empty `uri` representing user's snippets is not correctly handled
    if (!project) {
      repositoryRoot = await gitlabProjectInput.show(
        [
          {
            label: "User's Snippets",
            uri: '', // HERE WE RETURN EMPTY STRING
          },
        ],
        "Select a Gitlab Project or use the User's Snippets",
      );
      try {
        const selectedRepository = gitExtensionWrapper.getRepository(repositoryRoot); // HERE WE EXPECT SOME VALID URL
        project = selectedRepository && (await selectedRepository.getProject());
      } catch (e) {
        logError(e);
      }
    }

    const visibility = await vscode.window.showQuickPick(visibilityOptions);

    if (visibility) {
      const context = await vscode.window.showQuickPick(contextOptions);

      if (context) {
        uploadSnippet(project, editor, visibility.type, context.type, repositoryRoot); // THIS FUNCTION NEEDS VALID repositoryRoot
      }
    }
  } else {
    vscode.window.showInformationMessage('GitLab Workflow: No open file.');
  }
}
```

Story points: 1.0
Change TreeView to list repositories first and then filters

Follow-up from https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/345#note_569008314

### Problem to solve

As a user, I want to navigate my issues and <abbr title="merge request">MR</abbr>s using a “repository-first” hierarchy, so that its hierarchy matches other VS Code views and it doesn't make me think.

### Proposal

Change the extension's “Issues and merge requests” view to show repositories first and then the filters.

### Further details

| Current GitLab Workflow | explorer | source control | GitHub extension |
|----------|----------------|-----------------|-|
| ![settings_json___workspace](https://gitlab.com/gitlab-org/gitlab-vscode-extension/uploads/9a839aad560ebc8960a23c15e6430334/settings_json___workspace.png) | ![settings_json___workspace](https://gitlab.com/gitlab-org/gitlab-vscode-extension/uploads/785c11d232b242892b71bd444eb55cef/settings_json___workspace.png) | ![settings_json___workspace](https://gitlab.com/gitlab-org/gitlab-vscode-extension/uploads/4c68c4228d3bd0d15a3934c71d557de7/settings_json___workspace.png) | ![image](/uploads/3464d2984cf890c1b1122364bcbdf45d/image.png) |

### Links / references

Story points: 1.0
Add command to show merged YAML for CI config

### Problem to solve

As a developer, I want to be able to view the merged YAML for my GitLab CI configuration inside my VSCode workspace, so that I don't have to leave my IDE and navigate through a web browser to see the results.

### Proposal

Utilize the API endpoint to [Validate a CI YAML configuration with a namespace](https://docs.gitlab.com/ee/api/lint.html#validate-a-ci-yaml-configuration-with-a-namespace), retrieve the `merged_yaml` attribute from the response, and display the results in a separate editor.

### Further details

For complex pipelines, it can be very challenging to know whether the resulting merged YAML is going to look as desired/expected. Having the ability to view this directly in the developer's IDE would be extremely valuable.

### Links / references

Might be blocked by https://gitlab.com/gitlab-org/gitlab/-/issues/320778.

We can use virtual documents to show the merged result: https://code.visualstudio.com/api/extension-guides/virtual-documents.

- We'd define a `TextDocumentContentProvider` that will serve documents on a custom scheme URI (e.g. `gitlab-merged-ci-yaml`)
    - this provider would somehow have to store the API response
- We'd show the file by running `vscode.workspace.openTextDocument(customUri)`

Story points: 2.0
Support suggestions in VS Code diff comments

### Problem to solve

GitLab supports a custom suggestion Markdown code blocks

    ```suggestion:-0+0
    suggested text
    ```

Which gets rendered on the web as

![Update_new-file2_txt___9____Merge_requests___Tomas_Vik___test_project___GitLab](/uploads/6c6285cd99149ac0b2201b1bab5cad3b/Update_new-file2_txt___9____Merge_requests___Tomas_Vik___test_project___GitLab.png)

but in VS Code it renders as a generic text block:

![_Extension_Development_Host__-_new-file2_txt___9____test-project](/uploads/c141d97dfaf0ae44e25b5a5aba370575/_Extension_Development_Host__-_new-file2_txt___9____test-project.png)

### Proposal

Implement a post-processing of comments in VS Code to convert the custom suggestion into a diff block:

~~~markdown 
```suggestion:-1+0
,--,
```
~~~

changes to

~~~markdown
Suggestion:

```diff
- 
- ,,,
+ ,--,
```
~~~

rendered as

![_Extension_Development_Host__-_new-file2_txt___9____test-project](/uploads/99be510904a9514adc31334844d4b08b/_Extension_Development_Host__-_new-file2_txt___9____test-project.png)

### Further details

- This would be quite complex because as seen in the previous example, suggestion can span multiple lines (`suggestion:-1+0`) and so the logic would have to work not only on comments but also access the text file to have the full context.

### Links / references

Story points: 3.0
Warn users that they should use supported GitLab version

### Problem to solve

The extension doesn't work correctly with older GitLab versions (13.4 and older) (e.g. #347 #358). But the users don't have any way of finding this information and so the process currently looks like this:

1. GitLab instance returns an error
1. User creates a bug in extension issues
1. We try to help the user debug the issue
1. Eventually we ask about the GitLab version
1. User tells us an old version
1. We mark the issue as ~wontfix and explain to the user that we don't support old versions

### Proposal

#### Passive solutions

Passive solutions to the problem are trivial to implement, but they are not going to be as effective, because they rely on user reading the documentation for the extension.

- Add a note to the top of the README, that explains that the extension supports GitLab 13.5 and above.
- Add a section to the [Bug issue template](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/.gitlab/issue_templates/Bug.md)

#### Active solution

- When we start the extension, we can check the `/api/v4/version` response and if we find out that the version is lower than 13.5, we'll show the user a warning saying that they are connected to an unsupported version of GitLab instance and the extension won't fully work.

### Further details

- We already make use of the `version` endpoint: https://gitlab.com/gitlab-org/gitlab-vscode-extension/blob/c484feb48d44d8492a54be61b51637c781ef2b53/src/gitlab_service.ts#L170-181

### Links / references

/cc @phikai

Story points: 1.0
MR Review: track changed lines on the diff

### Problem to solve

This issue is a follow up for https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/340 that might be not necessary to implement if the https://gitlab.com/gitlab-org/gitlab/-/issues/325161 gets fixed.

This issue implements logic related to tracking which lines in the diff have been added/removed/unchanged. This feature needs to be behind a feature flag because we'll implement submitting new comments in a subsequent issue.

#### Commenting ranges

To be able to create new comments (not replies to a thread) we need to create a [`CommentingRangeProvider`](https://code.visualstudio.com/api/references/vscode-api#CommentingRangeProvider). We implement a function that receives a file URI and returns all the lines that the user can comment on.

Without these ranges, the user can only respond to existing comments (#339).

#### Track changed lines on the diff

To be able to submit comments on unchanged lines, we also need to be able to track position of unchanged lines across both old and new diff version. The `createDiffNote` GraphQL mutation requires both `oldLine` and `newLine` for unchanged lines (this is an issue tracked in https://gitlab.com/gitlab-org/gitlab/-/issues/325161). The following image explains the information we must compute:

![_Extension_Development_Host__-_gitlab_comment_thread_test_ts___197____gitlab-vscode-extension-TEST](/uploads/1d7b3ca4f7a9cfc00d91d5a6379156f5/_Extension_Development_Host__-_gitlab_comment_thread_test_ts___197____gitlab-vscode-extension-TEST.png)

To be able to submit a comment for the `it('deletes a comment', async () => {` line, we need to compute that the line has the number `133` on the old version but `149` on the new.

### Proposal

We'll need to use the textual diff that we retrieve from the [MR Diff version API endpoint](https://docs.gitlab.com/ee/api/merge_requests.html#get-a-single-mr-diff-version).

```json
{
  "old_path": "new_file.ts",
  "new_path": "new_file.ts",
  "a_mode": "0",
  "b_mode": "100644",
  "new_file": true,
  "renamed_file": false,
  "deleted_file": false,
  "diff": "@@ -0,0 +1,3 @@\n+export class NewFile{\n+    private property: string;\n+}\n"
}
```

We'll have to praise the `diff` property to find all changed lines.

### Further details

Example:

| no ranges | with ranges |
| ------ | ------ |
| ![gitlab_comment_thread_test_ts___197____gitlab-vscode-extension](/uploads/68d82d72b633a1cd187b1dbbb1973363/gitlab_comment_thread_test_ts___197____gitlab-vscode-extension.png) | ![_Extension_Development_Host__-_gitlab_comment_thread_test_ts___197____gitlab-vscode-extension-TEST](/uploads/f64380715c20a6a230e17dd8c95f00ce/_Extension_Development_Host__-_gitlab_comment_thread_test_ts___197____gitlab-vscode-extension-TEST.png) |

### Links / references

Story points: 2.0
MR Review: create a new comment on the diff

### Problem to solve

The extension only allows creating new comments on the "Details"  `webview` which means they are not related to any particular position. To replicate the GitLab web experience, this ~feature implements creating new comments in the MR diff view.

### Proposal

![new_comments](/uploads/cd27d196a2c53b0698650baf587d23e5/new_comments.mp4)

Implement a command that will be triggered when the user clicks "Add comment now" button:

![_Extension_Development_Host__-_test_ts___5____test-project](/uploads/0f1044ee573794ef21ec8f976982b545/_Extension_Development_Host__-_test_ts___5____test-project.png)

This command will create a new comment. It will support unchanged, removed, and added lines.

### Further details

#### Creating comments

GraphQL mutation

```graphql
mutation CreateDiffNote5 {
  createDiffNote(
    input: {
      noteableId: "gid://gitlab/MergeRequest/87196674"
      body: "new note"
      position: {
        baseSha: "5e6dffa282c5129aa67cd227a0429be21bfdaf80"
        headSha: "a2616e0fea06c8b5188e4064a76d623afbf97b0c"
        startSha: "5e6dffa282c5129aa67cd227a0429be21bfdaf80"
        paths: { oldPath: "/test.js", newPath: "/test.ts" }
        newLine: 15
      }
    }
  ) {
    errors
  }
}
```

All attributes are mandatory, except for the following exception regarding `newLine` and `oldLine`:

| type of line we comment on | newLine, oldLine explained |
| ------ | ------ |
| added line (right-hand-side of the diff) | We only submit `newLine` |
| removed line (left-hand-side of the diff) | We only submit `oldLine` |
| unchanged line | Both `newLine` and `oldLine` are **required**. If the unchanged line has a different index on each side of the diff, these attributes need to [reflect that different index](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/340#track-changed-lines-on-the-diff). |

#### Representing the new comment in VS Code

The `createDiffNote` mutation gives us only the new note as a response. But we need the full `discussion` response because only the discussion contains `replyId` attribute that allows us to submit replies.

In other words, without knowing the `replyId`, we can create a new thread, but the user can't reply to that thread.

The only way how we can get it now is to ask for **all discussions on MR** and filter out the one that contains our new note.

### Links / references

Story points: 4.0