Skip to content

"Open File at Revision" has incorrect editor label if revision contains path separator #2926

@ian-h-chamberlain

Description

@ian-h-chamberlain

Description

I'm not sure if this affects Windows or just macOS / Linux, due to having a different default separator.

  1. Create a branch with a / separator in its name, e.g. feature/foobar
  2. GitLens: Open File at Revision from... with the branch from step 1
  3. Observe the revision file editor title (it will be something like foobar)).

From what I can tell, this has been an issue for a long time which is also affected by VSCode implementation of the editor labels. It looks like part of this was originally implemented for GitLens in microsoft/vscode#68201 (comment) — but my guess is that either some VSCode behavior changed, or the final solution discussed there was never really implemented. I couldn't find any other issues about this resurfacing so I am opening it here.

Edit: another VSCode mention about this: microsoft/vscode#102739 (comment)
I wasn't able to find much else on VSCode repo, especially since they auto-stale and lock issues after a while, and this contribution API seems fairly limited in documentation, there doesn't seem to be much about this particular issue.

Edit2: I think the relevant VSCode implementation is here although I'm not an expert in their codebase: https://github.com/microsoft/vscode/blob/a6403e4552d39c1de87a24ad953d7d33be08cd74/src/vs/workbench/services/label/common/labelService.ts#L291-L305
https://github.com/microsoft/vscode/blob/a6403e4552d39c1de87a24ad953d7d33be08cd74/src/vs/workbench/services/label/common/labelService.ts#L446

After digging through the vscode implementation, there might be a couple paths forward:

  • Ask for a VSCode API in resourceLabelFormatters, which would skip calling basename on the URI or allow for a more precise format, maybe something like this?

    "formatting": {
      // could even use `${query.basename}` if the extension has to calculate the basename itself:
      "label": "${basename} (${query.ref})", 
      "separator": "/",
      "convertToBasename": false,
      "workspaceSuffix": "GitLens",
      "stripPathStartingSeparator": true
    }

    Alternatively, maybe they could support a syntax like ${query.ref:unescape}, or something like that, and the extension could percent-encode the ref to avoid the basename cutting it off (escaping would have to occur after basename trimming)? Maybe unescaping could even occur by default, for these ${} variables? Coming up with a solution without possibly breaking other extensions might be tricky.

  • Reimplement the hack solution mentioned in the linked comment above, i.e. pass something like U+1735 "᜵" in the query string and use it in the formatting.label. Downside of this is that copy-pasting the full path will end up with incorrect characters in the branch name, but I'm not sure how important that use case really is.

  • Other ideas? I think the best solutions all involve upstream VSCode fixes but the hack might be a nicer short-term solution just for usability.

GitLens Version

v14.3.0

VS Code Version

Version: 1.82.1
Commit: 6509174151d557a81c9d0b5f8a5a1e9274db5585
Date: 2023-09-08T08:49:32.930Z
Electron: 25.8.0
ElectronBuildId: 23503258
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Darwin x64 22.6.0

Git Version

git --version git version 2.42.0

Logs, Screenshots, Screen Captures, etc

Result after GitLens: Open File at Revision from... on a test branch:

Screenshot 2023-09-18 at 16 53 12

Metadata

Metadata

Assignees

Labels

Type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions