4 ms·
This implementation choice has always felt a bit odd to me, almost like premature optimization. Is there a reason to have done it this way other than storage de
by mikepurvis 2y ago
This implementation choice has always felt a bit odd to me, almost like premature optimization. Is there a reason to have done it this way other than storage deduplication? Since git is already a content-addressed store anyway, how hard would it have been to have some kind of abstraction below the repo layer that would provide the same deduplication?
At this point there's obviously huge inertia in Github's early architectural decisions, but if you were building Github today, would it still make sense to go this route?
- thomastjeffery 2y agoGitHub's fork feature works outside of git itself. It does not utilize the .git directory, and therefore does not utilize git's deduplication. EDIT: Oh, I see what you mean. It would definitely be interesting to solve this namespace conflict problem from inside git. I wonder how many times meta-branches (or something similar) have been advocated for.