git -C /tmp/tmp.5DzuMyMWOO bug user

This requires to use the git integration, which I don't think is the right choice for the future (even if it's cute).

That said, I'm not quite fan of the ergonomics of -c being a []string (some weird join of path segments) instead of a simple string (a single simple path). It seems to me that it's not the kind of thing we should carry over from git, even for an homogeneous experience.

Additionally, from a UX perspective we should consider how we will in the future instruct the webui command to load multiple repo, or a folder containing multiple repos, or ...

This requires to use the git integration, which I don't think is the right choice for the future (even if it's cute).

i mean, okay, if this move is made, but moving away from shipping as git-bug isn't something that's happening in the (near) future, doesn't have a complete design, should be aligned with a repository rename, and isn't the way users are expected to be using git-bug today.

since this wouldn't really cause an issue, i guess i'd accept it today even though the need for it is rather non-existent.

Additionally, from a UX perspective we should consider how we will in the future instruct the webui command to load multiple repo, or a folder containing multiple repos, or ...

this isn't the right place for design discussions, but generally, i see the server (a long-lived daemon running in the background) maintaining a list of repositories it should track/interact with. the user would add repositories to the server either imperatively (through a command, or api endpoint via a client application) or dynamically, by running any git-bug command in a repository that isn't already tracked.

A bit of confusion here and there regarding this entire proposal and pull request.

Git's -C flag is not (just) for specifying the path to the Git repository. It's for changing the current working directory. git literally does chdir when it encounters -C while parsing argv. Sure, you can use it to chdir to the root of a Git repo from somewhere else, but it's mostly used with deeply nested source trees to simplify commands and scripting.

The correct ways to specify the path to the Git repository (the .git directory) if you are running git from somewhere it can't be discovered automatically are the --git-dir flag and the GIT_DIR environment variable. As noted in #1467, one common use case for this is separation of working trees from repositories. While this might be out of scope because git-bug doesn't do much with the working tree (the actual tracked files), specifying the path to the .git directory is useful on its own, perhaps even more so when using git-bug than when using Git. It simplifies working with bare repositories, allowing to interact with bugs without checking out the files, and even using bare Git repos purely for task tracking, making them accessible from anywhere in the file system tree.

Real use case

yadm is a nifty POSIX Shell tool for managing "dotfiles". It's a Git wrapper designed to simplify tracking certain paths in your Unix home directory, like ~/.profile, ~/.bashrc, certain paths in ~/.config, etc. Because the files are all over the place and no one wants their home directory to be a giant Git working tree, yadm keeps the bare repository in ~/.local/share/yadm/repo.git.

yadm may be called from anywhere. Before running Git commands, yadm exports GIT_DIR to tell Git where the bare repository is. Because of git-bug's Git integration it should be automatically supported by yadm by calling yadm bug¹, but git-bug does not respect GIT_DIR, so it fails:

$ yadm status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit (use -u to show untracked files)

$ yadm bug bug
Error: .git not found

Worse, if someone calls yadm bug from inside another Git working tree, git-bug will actually modify that repository's bugs rather than those of the intended yadm repo.

This Pull Request

The implementation of -C as per this PR superficially mimics Git's -C and supports one of its use cases, but it may be confusing since the patched git-bug does not actually chdir as git does. Instead, all paths are concatenated and the resulting path is used as if it is the Git repository. This is made worse by the fact that git -C bug and git bug -C may result in completely different behaviours.

Suggestions

• rename -C to --git-dir;
• only allow specifying --git-dir once and make RepoPath a single string (removing the path concatenation behaviour);
• allow specifying the repository path via the GIT_DIR environment variable;
• leave everything else as is, do not worry about implementing --work-tree for now.

I might be available to implement this soon if everything makes sense.

👋 revisiting this.

Git's -C flag is not (just) for specifying the path to the Git repository. It's for changing the current working directory. git literally does chdir when it encounters -C while parsing argv. Sure, you can use it to chdir to the root of a Git repo from somewhere else, but it's mostly used with deeply nested source trees to simplify commands and scripting.

I don't think there is any confusion about how it works -- neither of the respondents claimed that it did anything other than what it does. That said, I would disagree that it is "mostly used with deeply nested source trees", as my own primary use case for it is automation that runs against many independent repositories, from outside of the context of any one of them - and you cannot possibly hope to know how the bulk of other git users use it.

yadm may be called from anywhere. Before running Git commands, yadm exports GIT_DIR to tell Git where the bare repository is. Because of git-bug's Git integration it should be automatically supported by yadm by calling yadm bug1, but git-bug does not respect GIT_DIR, so it fails.

this is true - but this PR doesn't address GIT_DIR, and i'd rephrase the comment from @MichaelMure about refraining from requiring integration with git as something along the lines of "let's refrain from a deeply nested architectural decision that would prevent us from supporting other backends that are not git, or that would prevent us from moving git-bug into a standalone program that did not integrate as a git subcommand", as i believe that is the spirit of the comment (but any subsequent comment he makes to clarify this should overwrite this opinion). It was a response to my suggestion that git -C <path> bug ... was the recommended approach, anyway.

more to the point, I don't think calling git-bug from within another program that manages the current context the user runs it in is a use case that has been considered thus far. This isn't to say that we would reject patches which support doing this, but that those patches need to make sense for git-bug independently.

more to the point, I don't think calling git-bug from within another program that manages the current context the user runs it in is a use case that has been considered thus far.

This is exactly what I was doing until I realized that:

1. I needed a different execenv for other reasons.
2. The parameter parsing done by the Cobra commands wasn't needed and in fact allowed too many options.

So now I'm using git-bug as a library. I have another app I've been toying with that might need this feature though.

That being said, I'm happy to update this PR once we've reached a consensus. As an alternate view-point, I never run git-bug as a git sub-command but that's really just habit as git-bug bug and git bug bug are similar to type.

i don't think that the current working directory is an appropriate default - i think we should instead get the repository's root directory, to support this workflow for users who are in some subdirectory of the repo.

Great point!

So what I think I've heard so far is:

1. Support --git-dir and GIT_DIR
2. The default should be the CWD if it contains .git or traverse to a parent that does have .git. And error if we're not in a repository at all.

@sudoforge Can you re-review this when you get a chance?