GitLens creates a `.gk` folder in the home dir.

[lgarron]

Description

1. Use the extension like normal?

GitLens Version

v15.6.0

VS Code Version

Version: 1.94.0 Commit: d78a74bcdfad14d5d3b1b782f87255d802b57511 Date: 2024-10-02T13:08:12.626Z (6 days ago) Electron: 30.5.1 ElectronBuildId: 10262041 Chromium: 124.0.6367.243 Node.js: 20.16.0 V8: 12.4.254.20-electron.0 OS: Darwin arm64 24.0.0

Git Version

git version 2.45.0

Logs, Screenshots, Screen Captures, etc

A .gk folder has started appearing in my home directory, containing a repoMapping.json file. This seems to be due to: https://github.com/gitkraken/vscode-gitlens/blob/b99d04597b46c0c59e9e56adb01db82a8974e089/src/env/node/pathMapping/sharedGKDataFolder.ts#L60

Creating a folder directly in the home dir is not a great practice. The appropriate thing would be to use the XDG conventions, possibly supplemented by platform-specific conventions.

VS Code may provide an API for this to extensions, else there are a bunch of libraries for this: https://www.npmjs.com/search?q=xdg

Alternatively, creating repoMapping.json inside e.g. ~/.data/gitlens would be much, much better than the current behaviour.

[eamodio]

This is by-design as that folder and its configuration is shared between our (GitKraken) tools (GitLens, GitKraken Desktop, and GitKraken CLI)

[EXHades]

“This is by-design”，thank you for openSource work

now just run code --uninstall-extension 'eamodio.gitlens' fix issue

[lgarron]

This is by-design as that folder and its configuration is shared between our (GitKraken) tools (GitLens, GitKraken Desktop, and GitKraken CLI)

Does this mean you are not open to any changes to moving the default location for that folder? 😕

[eamodio]

Correct, our tools use that as a well-known location. It is also quite a common location for many tools.

[lgarron]

Correct, our tools use that as a well-known location. It is also quite a common location for many tools.

This is disappointing to hear, but is there anything that would change your mind? I would be happy to send a PR that uses an updated location when the old location is not present.

Many projects already use XDG-compatible conventions, and many have transitioned after listening to their community. Some of us see openness to this kind of improvement as a litmus for how a project is willing to listen to feedback.

[eamodio]

Can you point me to other tools (vs code in particular) that do this? What would it look like?

But as I said this isn't just a change that GitLens can make because our other tools rely on these same files.

[lgarron]

Unfortunately I don't have a large list of tools that follow the XDG conventions, as by definition I will not notice folders from them.

However, https://wiki.archlinux.org/title/XDG_Base_Directory lists a large number of projects that used to have this issue but many of which have either moved their default folder or added a configuration option to change the location.

Here is a selection based on a quick search of my GitHub notification history:

• https://github.com/chromium/trickuri/pull/18#event-2111051957
• https://github.com/pqrs-org/Karabiner-Elements/pull/114#event-908525492
• https://github.com/rubygems/rubygems/pull/3545#issuecomment-1283788635
• https://github.com/oven-sh/bun/pull/1351

[untainsYD]

Correct, our tools use that as a well-known location. It is also quite a common location for many tools.

no it's not quite common, you are violating XDG DESKTOP PATH, you should google "common" folders before writing this nonsense @eamodio

[eamodio]

@untainsYD keep this constructive

[untainsYD]

@untainsYD keep this constructive

oh, no, sorry, you are not constructive, you have broken the default path on Linux, and saying that it won't be fixed, coz you don't know (or dont want) how to set xdg data default path for Linux

@eamodio see https://github.com/microsoft/vscode/issues/162712, and XDG_DATA_HOME in https://wiki.archlinux.org/title/XDG_Base_Directory, https://specifications.freedesktop.org/basedir-spec/latest/

[BurnerWah]

Can you point me to other tools (vs code in particular) that do this? What would it look like?

But as I said this isn't just a change that GitLens can make because our other tools rely on these same files.

I'm pretty sure that SQLTools follows the XDG spec, if you want VSCode-specific.

Also, fwiw there's been a feedback suggestion for GitKraken itself to add XDG compliance since 2021.

I'd honestly be okay with even just having a GITKRAKEN_HOME environment variable so I can just put the .gk folder elsewhere. I don't actually use any of the other tools that rely on the .gk folder, so it's not really doing anything on my system. (well actually it doesn't exist because my home folder permissions prevent its creation entirely)

[untainsYD]

well actually it doesn't exist because my home folder permissions prevent its creation entirely

Can you share how you achieved that?

[sdball]

I found this issue searching for what tool in 2024 could possibly have written a new folder in $HOME on my macOS machine. The standard by far is to use $XDG_CONFIG_HOME or falling back to $HOME/.config/...

I am very disappointed to find that this isn't considered an issue and I'll simply stop using gitlens in VSCode.

[DusanLesan]

This is a deal breaker for me. If you don't start fixing it soon, I'm out.

Programs that do not respect the XDG specification are an exception as you can see in this shrinking list of current and past offenders: https://wiki.archlinux.org/title/XDG_Base_Directory

It was previously mentioned as a possible solution to use environment variables like GITKRAKEN_HOME. I disagree in this case. That approach is mainly used to preserve compatibility in well-established programs that have used incorrect paths for a long time. Here, this is a recent regression, and it should be done correctly from the start.

[BurnerWah]

well actually it doesn't exist because my home folder permissions prevent its creation entirely

Can you share how you achieved that?

chmod -w $HOME Only tested on Linux, and it can break some desktop environments (I use GNOME on Fedora Linux, but last time I used KDE it wasn't happy), but if it works, it works very well. As long as no mount-related things happen, everything either just silently errors out or crashes instead of creating dotfiles.

Combined with some wrapper scripts to give things that do create dotfiles an alternate home folder (I use a very overengineered solution to this but just changing what $HOME to something else for a moment works too), and a... probably excessive utilization of flatpaks, you'll end up with an immaculate home folder.