@jgoerzen @alcinnz last i checked #bugseverywhere was dead upstream and removed from Debian https://tracker.debian.org/pkg/bugs-everywhere i'd look at https://github.com/MichaelMure/git-bug/ if i'd need to manage issues over #git

@alcinnz Ooo, #BugsEverywhere looks nifty! Thanks!

@sir #BugsEverywhere is an intriguing project doing what you were talking about a few days ago; integrating the bug tracker data into the Git repo itself
http://bugseverywhere.org/

@musicmatze Oh yes, I'm assuming there are real tools, I just appreciate a data model that can be inspected without them!

You mentioned on https://github.com/neithernut/git-dit/blob/master/doc/use-cases.md as well that issues could be easily transferred to other repos, but that would be the case only if they don't refer to (as secondary parents) actual code from the repo.

Anyway, I think the model is really interesting, and here's why:

There is a sort of tension in git-based #distbugs whether one should have issues in files along with the code or in files in a parallel branch.

When the issue lives with the code, it's really cool because you can comment on the bug as you update the code, and your commit that fixes the problem can be the commit that also closes the issue in the issue data.

When the issue lives in its own branch, it becomes unproblematic to have an issue that affects several code branches, and the discussion can be kept in one place instead of spread out in all those branches.

With your approach, it seems you can have it both ways. The issue lives in its own commit chain, but as it contains no tree, it's trivial to merge in with a commit that fixes something, so you can still get that connection. As each issue has its own root, it's not even a problem to refer to the issue from several code branches.

The space has felt quite abandoned for some time, I've been using the #bugseverywhere version from 2013, but I've been hoping that something more would happen in the field, especially tying web issues into the whole thing. It sounds like creating issues is on the roadmap for git-dit-wui?

I'll definitely look at what your tools can do. Thanks for your work!

And now I noticed that you're actually the one who updated the dist-bugs page. Good. Good. :-)

I think @joeyh and @liw might be interested to hear about #gitdit also.

Matěj Cepl* forked #bugseverywhere to https://gitlab.com/bugseverywhere/bugseverywhere at the point of #gitoriocalypse, but it has seen only sporadic commits, mostly spelling fixes in the docs, since the first small spurt.

* https://matej.ceplovi.cz/

What I dislike about #gitlab, #gitea, #gogs and other similar projects is that any user who wants to contribute to one of your repos must create an account in your instance. So, you are forced to run a public instance. It's unpleasant business to run large public instances. It becomes a single point of failure. And, benefits of decentralization are diminished or lost.

We need something P2P or federated for hosting git. Some approaches I've heard of are #gittorrent, git over #ipfs, #bugseverywhere and #ditz. However, many of these projects are inactive and don't seem to be maintained. :-(