| ▲ | Ericson2314 9 hours ago |
| The Nixpkgs example is not like the others, because it is source code. I don't get what is so bad about shallow clones either. Why should they be so performance sensative? |
|
| ▲ | 8 hours ago | parent | next [-] |
| [deleted] |
|
| ▲ | ajb 9 hours ago | parent | prev | next [-] |
| In a compressed format, later commits would be added as a delta of some kind, to avoid increasing the size by the whole tree size each time. To make shallow clones efficient you'd need to rewrite the compressed form such that earlier commits are instead deltas on later ones, or something equivalent. |
|
| ▲ | __MatrixMan__ 8 hours ago | parent | prev [-] |
| It also seems like it's not git that's emitting scary creaks and groans, but rather GitHub. As much as it would be a bummer to forgo some of GitHub's nice-to-have features, I expect we could survive without some of it. |
| |
| ▲ | MarsIronPI 5 hours ago | parent | next [-] | | Exactly. Gentoo's main package repo is hosted in Git (but not GitHub, except as a mirror). Now, most users fetch it via rsync, but actually using the Git repo IME makes syncing faster, not slower. Though it does make the initial fetch slower. | |
| ▲ | mindslight 7 hours ago | parent | prev [-] | | Furthermore, the issues given for nixpkgs are actually demonstrating the success of using git as the database! Those 20k forks are all people maintaining their own version of nixpkgs on Github, right? Each their own independent tree that users can just go ahead and modify for their own whims and purposes, without having to overcome the activation energy of creating their own package repository. If 83GB (4MB/fork) is "too big" then responsibility for that rests solely on the elective centralization encouraged by Github. I suspect if you could go and total up the cumulative storage used by the nixpkgs source tree distributed on computers spread throughout the world, that is many orders of magnitude larger. | | |
| ▲ | __MatrixMan__ 2 hours ago | parent [-] | | Agreed, nix really makes it easy to go from solving the problem for yourself to solving it for everybody. Not much else is easy, but when it comes to building an open source community, that criterion is a pretty powerful one. |
|
|
