6 ms·
> the repo "network" This is actually an optimization done by GitHub. It would take up a lot of space if GitHub copied the entire repo every time someone fork
by smitop 7y ago
> the repo "network"
This is actually an optimization done by GitHub. It would take up a lot of space if GitHub copied the entire repo every time someone forked it, so they keep all the commits in the original repo. As a side effect, commits in forks are accessible from the original repo since commits from both repos are stored in the same place.
- argd678 7y agoHow do they know which branch in my fork is mine vs upstream? Or in the case where I modify a forked branch?
- emmelaich 7y agoA branch is just a series of commits; if any one of the commits has a different hash (as this hack will do) then the commit and all following commits will have a different hash. Including the id of the branch (the HEAD).
- ajross 7y agoIt's sort of the reverse: they can't know, from a bare commit ID, what repo it "belongs" to without searching backward from every tag or branch in the repo. (Even that question is malformed: repos have histories and may have contained commits in the past that are no longer ancestors of existing branches or tags). So they just fake it: they look in their database to find any commit with that SHA and put it up. And that database happens (for obvious performance reasons) to be shared between a repo and its forks.
- odyssey7 7y agoI'd imagine this is why GitHub disallows private forks?
- heftig 7y agoYes. If they did this, private commits might even leak into packfiles fetched from GitHub by git.
- SilasX 7y agoGP isn't saying GitHub should copy the entire repo, only that there should be some indication that the code you're looking at isn't the repo owner's (despite being committed in their name and on a repo they "control"). I don't see what optimization requires that. They already keep track of e.g. me pushing up someone else's commit after a rebase -- it indicates that I pushed but the commit originally came from someone else.
- orf 7y ago> I don't see what optimization requires that. From a single commit ID you cannot tell which repo it came from. A "repo" is just a tree of commits.
- nitrogen 7y agoThen it should be possible to store the originating repo along with the commit so that commits aren't visible in a given "repo" until they are pushed or pulled into that repo
- orf 7y agoStoring all commit origins at the scale of github is the expensive part.
- SilasX 7y agoGood thing Github is allowed to associate data with a commit ID, like they already do with rebased commits, as noted in the subsequent sentence.