> Git doesn't include better built-in support for issues, wikis, PRs / code reviews, and releases

I feel like a lot of these features could be handled with git-notes[1]. For example git-appraise[2] uses the git-notes feature for a code review system:

[1] https://git-scm.com/docs/git-notes

[2]https://github.com/google/git-appraise

Somewhere around 2009-2012 there was also a lot of experimenting going on with distributed issue tracking, such as with Bugs Everywhere [0] (and like 3 or 4 others I tried some time ago that I can't find now).

That said, it seems like there was a resurgence - I found two, git-issue [1] and git-dit [2], that have both had activity this year. And git-dit has shown up on here at least once before, as well [3].

[0] https://github.com/aaiyer/bugseverywhere

[1] https://github.com/dspinellis/git-issue

[2] https://github.com/neithernut/git-dit

[3] https://news.ycombinator.com/item?id=13732598

Part of the challenge is that for issue tracking to really work for non-trivial projects is that there needs to be some web interface that allows newcomers to report issues without first obtaining commit access to the main repository. If some of the solutions can get this bit of functionality then they stand a chance of doing some really awesome things (I'd love to be able to work on and update issues while totally offline).

Right now they do still unfortunately come off as toy examples once you get to the point where their distributed nature would normally come in handy. It's a shame that the interest in the problem died down a few years back around the time you noted.

Thanks for sharing, I'd never heard of git-notes before! That's really cool. I'd previously wondered why there wasn't something like this available; it looks like I just wasn't aware of its existence. I definitely agree that you could implement many powerful features using this.

Now I'm wondering if someone has implement a release tracker using git-notes. After you tag the release you could build / generate the output assets (e.g. binaries), upload them to some remotes (e.g. S3, GitHub, your server), and add a note with the release info plus some links.

I've already thought up a couple ideas for things that could be built on top of git-notes.

I'm glad to see Fossil mentioned here. Yet the real problem is not in the technical aspects and possibilities of project hosting migration, it's the dependence of the majority of open-source developers on GitHub's centralized social network.

Hopefully if this turns GitHub evil, other social networks can be leveraged to assist in a population migration. Like, someone posting a link on Twitter to wherever the repo will exist in the future.

This makes me wonder how hard it is to securely host a git server on my own. I'll start googling but I bet the answer is gonna be "hard."

The only hard part is securing your server, since setting up a remote git server only requires two things:

1. Running git.

2. Providing SSH access.

But even securing the server is not necessarily difficult, depending on the level of risk acceptable for your purposes.

Put another way, reasonable security is not too hard and AWS makes reasonable security fairly easy. Even self-hosted *nix servers can be pretty secure. However to seriously harden a service against skilled and determined attackers requires an experienced team and even that may not be enough.

What social network? The stars and follows? Does anyone actually care about them? Why? I've never seen the point.

They’re a decent measure of the reputation and stability of a project. I also use the stars to bookmark my projects for later.

The developer identities that link developer activity across all projects, the network of forks.

forks, pull requests and review comments

Not much of a network effect, there. You go where the code base you want to participate in is.

It's harder to find contributors for a project that is not hosted on GitHub.

I wouldn’t want git to have built in wiki’s, bug trackers etc. I think it’s better to have separate tools.

Point being, the data can and should live within the repo like gh-pages has been doing for a while. Not about those tools being integrated to official git tooling.

> I think it’s better to have separate tools.

The amount of people using GitHub shows otherwise.

I’m glad to see Gitea commented here. I’ve been using Gitea at work for about 3 months now and really enjoy it.

With tools like SIT (https://sit.fyi) you can keep your issues and patches inside of the Git (or other SCM) repository.

Pagure (https://pagure.io/pagure) combines a simple Git hosting forge with SIT-style issue tracking. On top of the code itself in Git, Pagure also uses Git for managing issues. So you can even use Git to comment on things. :)

Also, for those interested, Pagure lets you live a JS-free life too. ;)

I've been using it for several months on pagure.io, and it's my preferred Git-based hosting for my private stuff locally.

EDIT: GitHub repo importer: https://pagure.io/pagure-importer

Yes, Pagure is also a great project!

At my level of understanding it, the main difference between Pague and SIT is that SIT's story is more about decentralization (and SIT also provides its core to other potential applications beyond software development niche)

Is someone doing this for the entire website?

Give it 7-10 years before it is riddled with advertisements or has a subscription fee for 'premium' downloads.

Unless I misunderstand the need you describe, git can in fact bundle in at least two single-file formats.

Can it bundle "issues, wikis, PRs / code reviews, and releases"?