Support namespaced instances of git-bug

[rafasc]

git-bug supports fetching from multiple repositories but once bugs are fetched they all go inside the same bag: .git/refs/bugs/<oid>. This makes it impossible to keep bugs from different sources separate.

Use cases can be:

• public and private bug trackers.
• pulling and pushing bugs from multiple forks while keeping them separate.

When it comes to namespacing references, the usual solution in git is to just make a path based namespace scheme. So using something like .git/refs/bugs/default/<oid> would be the easiest solution to allow the use of other namespaces, e.g. .git/refs/bugs/private/<oid>

Another possible candidate is gitnamespaces as in https://git-scm.com/docs/gitnamespaces.

And of course, something would need to be done about the global state stored on .git/git-bug.

Thoughts?

[MichaelMure]

Just a note, this could also be handled by tagging bugs with metadata instead of physically shard them on disk.

As with many feature request, I'd like to have more user opinions, to see who need that and for what, to make sure this is actually useful, and to tailor the design to the actual usage.

[rafasc]

Just a note, this could also be handled by tagging bugs with metadata instead of physically shard them on disk.

But then you're losing some the pros of bugs being stored as references in a repo. E.g. moving bugs around even if you don't have git-bug available should be as simple as:

$git push remote refs/bugs/*:refs/bugs/*; 
# or something like this if it supported pathname based schemes:
$git push remote refs/bugs/[somename]/*:refs/bugs/[someone]/* #

Tags, branches, remotes, notes, essentially all types of refs can be namespaced using pathname schemes. On top of that, the entire .git/refs/* hierarchy can be namespaced again under refs/namespaces/<somename>/. Namespacing is a essential feature to maintain the distributed nature of git.

As it currently stands, git-bug is working like a centralized bugtracker in reverse.

Let's say someone doesn't like some aspect of git-bug forks it and starts developing independently. An impartial user can add both repos as remotes and build his own custom version. Git has no problem supporting this workflow.

But once this user pulls a bug from repo B he can no longer push back to repo A. Worse, if the user pulls from A and then B he can no longer contribute back to either repo because A and B might not be interested in the bugs of each other.

And yes, handling this with additional metadata is possible. But I value the ability to transfer bug references across machines with git itself and namespacing should be familiar to anyone using git.

[hoijui]

a +1 with my own reasoning

for me, one of the essential qualities of git, is that one is able to fetch from any repo, then look at it locally while still having them separate. then I can use for myself only what I care about and deem worthwhile.

This should be the same for bugs, with maybe the exception of a kind of centralized, public version of the repo, which could be configured to auto-accept all bugs into its own name-space. It should be the special case, and not the default (or even the only possible) behavior.

I think with this lacking, it will make many devs feel a kind of loss of control they have come to value and expect from normal git workflow with code. One might feel very reluctant to fetch other peoples repos, simply because one does not want to risk getting spammed by others bugs.

[LemmingAvalanche]

+1. This makes sense.

I currently use git bug as my private issue tracker. Local, only accessible to me—great. But the issues might be of interest to others. Letting them import them under a separate namespace would be nice.

(If that would also help against merge conflicts, that would be great. I have no idea though since I don’t know how git bug is implemented.)

I also don’t want to use SHA-1 for bug ids. git bug probably probably doesn’t support incrementing ids so I’ll probably just do it manually. Then with my namespace the issues could be identified with <namespace>-<integer>.

[github-actions[bot]]

This bot triages untriaged issues and PRs according to the following rules:

• After 90 days of inactivity, the lifecycle/stale label is applied
• After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

To remove the stale status, you can:

• Remove the lifecycle/stale label
• Comment on this issue