Separate `.gitopolis.toml` location from current working directory to allow running from anywhere

[peteringram0]

The .gitopolis file is currently generated relative to the binary location. This setup works for users who download the application, place it alongside their Git repositories, and manually update it. However, most developers prefer installing tools via package managers for ease of installation and updates—Homebrew on macOS, winget on Windows, and various package managers like apt or yum on Linux.

The main obstacle preventing Gitopolis from being installed via these package managers is the config file location, which is currently referenced from a non-managed directory. Since Gitopolis should be accessible from anywhere within the PATH, it requires a standardized config file location across all supported systems.

Therefore, I propose standardizing the config file location across the supported platforms. For Windows, I would need some suggestions as I am not very familiar with it:

System	Location
MacOS	~/.config/gitopolis.toml
Linux	~/.config/gitopolis.toml
Windows	%LOCALAPPDATA%\gitopolis.toml

This change would prepare Gitopolis for inclusion in package managers.

[timabell]

Oh, that's odd. It puts it in the current working directory for me (linux) rather than where the binary is. That was the intention rather than some central location

[peteringram0]

Oh, that's odd. It puts it in the current working directory for me (linux) rather than where the binary is. That was the intention rather than some central location

If the application is in PATH you need to then remember the dir that you last ran in to get your current list etc?

[timabell]

If the application is in PATH you need to then remember the dir that you last ran in to get your current list etc?

I always run it from the parent directory of all my repos, it had never occurred to me to run it from anywhere else.

[peteringram0]

If the application is in PATH you need to then remember the dir that you last ran in to get your current list etc?

I always run it from the parent directory of all my repos, it had never occurred to me to run it from anywhere else.

I think its worth considering.

Personally i spend my life in the terminal and I can be at any path. Additionally many people backup their dot files (me included) so having a config that can move across machines with me is a big benifit.

[timabell]

Yeah it's a good point, I'll give it some thought. Feel free to remind me IRL too

[timabell]

The path is currently hard-coded to just the filename here https://github.com/rustworkshop/gitopolis/blob/232f7f4f86559af6a244040dc81ceff467eca3ed/src/main.rs#L128

I tried changing it to a hard-coded path just to see what it would do, it works

const STATE_FILE: &str = "/home/tim/tmp/.gitopolis.toml";

We'd need to figure out where to put a global config file - Crate than provide cross-platform paths - https://github.com/dirs-dev/dirs-rs - should do the job.

We'd also need to figure out a good way to decide whether it should be using the global location or the current folder. Especially as the add command will create the config if missing.

It's important to keep the simplicity of usage of the tool. I don't want this to become another tool that is complex to use.

In terms of finding the file if it exists that should be fine because it can check the current folder first then fall back to global home folder if not found.

I think where to create the file in the first place with the first add is the tricky thing to keep nice. I'm open to suggestions but intend to be fussy about keeping it really clean.

[timabell]

I've been thinking more about this

For reads it could either try global location first or local first, then fall back to the other.

For writes it's a bit less obvious what to do. Particularly when there are no existing config files for it. Should it default to global or should it default to the current folder.

asdf-vm provides an interesting model - https://asdf-vm.com/guide/getting-started.html#_6-set-a-version - it walks the folders up to ~/ looking for .tool-versions files and uses the first one it finds for each tool.

I guess the question is which is the most common use case, and how hard does it make switching to the other use case if we default to one or other:

1. One global gitopolis config for all repos
2. Multiple gitopolis roots (e.g. ~/personal/ ~/client1/ ~/client2/)

I personally make use of the latter approach, but I can see that's surprising if you think of gitopolis as a global tool for managing all your repos anywhere in $HOME

This issue needs a detailed design of intended behaviour that shows how the use cases trade off against each other in practice and what the commands and config would look like.

global first

i.e. default behaviour from scratch is to create and use a global config for the user

• default location ~/.gitopolis.toml
• could look for closer config like asdf does if in a subfolder

still needs to support config files in subfolders as that's how I use it

read:

• find nearest file, treat that as entire config

write:

• find nearest file, write to that
• if no file found create the global config

creating a nested config:

if the user wants to create a config at a nested location we need a way for them to do that, and we need to avoid the global config being duplicated into it due to the way gitopolis loads everything into memory, modifies it, and writes it all back out again.

maybe a gitopolis init to be run in the subfolder that creates an empty config

could have optional path gitopolis init ~/some/subfolder/ to avoid having to cd

This option seems fairly clean from a UX point of view.

local first (current)

i.e. default behaviour is as is currently the case where it will create a config in the current working directory wherever that happens to be

we could potentially add an additional global fallback

we'd need a way for the user to create the global config

I think I like this option less from a UX point of view

path handling

both options need a bit of thought for repo paths in the config.

currently it stores paths relative to the config file, because that's where you have to run the command from. This has the benefit that if you move your whole repo folder or use a symlink then gitopolis doesn't care. It also allows you to share the config with colleagues and they can re-clone all the repos into whatever parent folder they feel like

anything global would probably need to use full paths from ~/ which would make the config less portable... though I suppose if you know that then you could make sure the client/work config is done in the repos subfolder rather than globally, and it wouldn't be too much hassle to sed the file to fix it up if you want to move it, being plain text paths after all