[ja3k]

Thanks! Yeah it was fun to do. Once I had the idea I felt compelled to implement it.

It is a little wasteful to fork the whole repo to make a comment. But it seems unavoidable with this design.

[Operyl]

Forks don’t actually create a copy of the git objects, so effectively it’s just a row in the database.

[brnt]

Then how come Github shows you the photocopying page, sometimes for quite a while? It takes long enough to convince me it does more than set a pointer.

[Operyl]

It's not "just a database row," I oversimplified a bit too much perhaps, but it pretty much is very very little in the way of data. Since the following blog post, more stuff has been added to Git (2018, iirc): https://gitlab.com/gitlab-org/gitaly/blob/master/doc/delta_i... https://gitlab.com/gitlab-org/gitaly/-/issues/1519

https://github.blog/2015-09-22-counting-objects/

> Very early on we figured out that actually forking people’s repositories was not sustainable. For instance, there are almost 11,000 forks of Rails hosted on GitHub: if each one of them were its own copy of the repository, that would imply an incredible amount of redundant disk space, requiring several times more fileservers than the ones we have in our infrastructure.

[zauguin]

I don't know, but since GitHub allows you to show commits from any fork with a URL referencing another fork, GitHub seems to use a common object store for all forks.

Maybe setting up the separate issue tracker and Pull Requests takes some time?