[avgcorrection]

And Fossil is an entirely different VCS.

What’s the alternative? That at least N projects cooperate and agree on a common design before they do the implementation? (Then maybe someone can complain about design-by-committee.)

[chriswarbo]

I use Artemis, which was originally written for Mercurial but also supports Git. It stores issues inside a repo, so it doesn't care about where it's hosted and works completely offline without needing a Web browser. Issues are stored in Maildir format, which is widely supported standard that can be processed using off-the-shelf tools. For example, I write and comment on Artemis issues using Emacs message-mode (which was designed for Email), and I render issues to HTML using MHonArc (which was designed for mailing list archives).

I'm not claiming these tools are the best, or anything. Just that existing standards can work very well, and are a good foundation to build up UIs or whatever; rather than attempting to design something perfect from scratch.

My fork of Artemis, patched for Python3: http://www.chriswarbo.net/git/artemis

Emacs config to trigger message-mode when emacsclient is invoked as EDITOR on an Artemis issue: http://www.chriswarbo.net/git/warbo-emacs-d/git/branches/mas...

An example of HTML rendered from Artemis issues: http://www.chriswarbo.net/git/nix-config/issues/threads.html

[account42]

> What’s the alternative? That at least N projects cooperate and agree on a common design before they do the implementation?

That would be ideal, yes. You should solicit comments from the greater community before setting the format in stone. But the very minimum would be to build on existing attempts at issues-in-git like [0] instead of reinventing the wheel unless you have a very very very good reason.

[0] https://github.com/MichaelMure/git-bug

[9dev]

Yes! That's exactly what I would like to see - come together as a working group, create a PR on git itself, and implement standard support for issues, PRs, discussions, projects, votings, project websites, what-have-you. The community will take it from there.

The alternative to that would be the git project itself coming up with an implementation. They have reasonable experience working with the Kernel, and the creation of git itself seems to have worked reasonably well -- although I'm not sure I would want to use something Linus considers ergonomic :)

[avgcorrection]

Ok. That could work if you found a group of people who are interested in such an all-in-one package. Gitlab is apparently working on a sort of cross-forge protocol (probably motivated by connecting Gitlab instances) and it seems that some Gitlab employees are working full time on the Git project. So those are candidates. You probably need a group which both have recognition within the project and are active enough to drive such a project forward without it fizzling out.

Without such a group you might just send a few emails to mailing list, get shrugs about how that plan “looks good” with little real interest, and then have to discuss this big plan in every future patch series that incrementally builds such a thing into Git itself. Mostly why such code should be incorporated and how it will pay off when it’s all ready.

The Git tool itself—and the project by extension—is per now very unopinioated about whole-project solutions like this. The workflow that they themselves use is very loosely coupled and pretty much needs bespoke scripting by individual contributors, which I guess is telling in itself.

[account42]

I would have like to have seen what kind of issue resolution labels old Linus would have come up with. Resolved: YOU GIT has a nice ring to it.