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:

vscode-gitlens/src/env/node/pathMapping/sharedGKDataFolder.ts

Line 60 in b99d045

return Uri.file(path.join(os.homedir(), sharedGKDataFolder, 'repoMapping.json'));

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)

[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:

• Change default storage dir to match $XDG_CONFIG_HOME. chromium/trickuri#18 (comment)
• Use xdg config home convention pqrs-org/Karabiner-Elements#114 (comment)
• Support XDG specification rubygems/rubygems#3545 (comment)
• Cache dir loader: Prefer $BUN_INSTALL and $XDG_CACHE_HOME to $HOME. oven-sh/bun#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 microsoft/vscode#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.

[jmtornetta]

Agreed, this is a bad convention. A lot of us version control the home folder or have scripts that run recursive actions on folders in $HOME on a cron/systemd. This creates more work.

[TilKenneth]

Hello from the Windows world.
I have 19 dot-dirs and 8 dot-files, I also have these absolutely useless symlinks dangling in $HOME under threat Windows decides to make that its last stand.

Clutter.

I have to scroll to find my "Tools" directory, I even have %TOOLS% as a shortcut to skip this, the scrolling on my mouse has torn it old. Because .gitconfig, mercurial, the Bbash-4-Windows-dot-mess and their random configs everywhere, I somehow have .aws and some totally undecipherable .gk directory, with only hint is a json related to gitmapping, a need I presume, because another unrelated useless directory.

You have %AppData% and %LocalAppData%, you even have the whole Windows Registry to hide in aswell, you also have %ProgramData%, i mean there are dead symlinks morphing into another language depending who "looks" at them, dangling and unclicable, because of options.

I am not a daily linux driver, but I really, realllly do appreciate the XDG-env vars thingies, I can remap you - free to choose, free as in freedom to do what I want if it suits me.

Now that I came here, I do know I have this extension. Lets imagine I feel the freedom to remove it, I assume your product will clean up, properly, like most serious Windows uninstallers?

---

Anyway, I really just came here to say, stop this cluttering. Please have a nice week, and I will take my goodbye for now!

[brendanzab]

It would be great for it to be in a XDG-compliant location on macOS too (which is what Git itself does). That said, I’m already going to be moving to Better Git Line Blame… this is just the thing that’s pushed me to fully uninstall GitLens.

I’ve been working really hard to get all the dotfiles out of my top-level home directory, and it’s a bit frustrating to have another pop up, then have to track down where it’s coming from! It’s also particularly annoying in this case because ~/.gk doesn’t give any sign that it’s coming from GitLens, so you’re left relying on search engines.

[amorphobia]

I’m already probably be moving to Better Git Line Blame

Thank you! This is constructive!

[ebits21]

Just to chime in, I’m cleaning up my home folder today and wondering what the .gk and .gitkraken folders are that are junking up my home folder.

Please follow xdg standards. You can move your config I’m sure. Pleaseee.