Hacker News Reader

Comment by SilasX | Hacker News Reader

GP 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.

View on HN

> 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.

Even if you're deduplicating commits / data internally, you can tell that that commit is not present in that repo as it is not an ancestor to any ref in that repository.

(You might argue that determining what refs contain a commit is potentially expensive, perhaps, but GitHub already does this, so I'd argue that it's not that expensive.)

Then 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

Storing all commit origins at the scale of github is the expensive part.

Good thing Github is allowed to associate data with a commit ID, like they already do with rebased commits, as noted in the subsequent sentence.

This information is part of the commit created by git and not "associated data" added by GitHub.

Really? Where is git storing it? I don't see any information about my rebases in the message, or who pushed it.

github doesnt use plain bare repositories for their repo hosting, so they can do whatever they deem useful :)

if they did you'd be spot on though

Reply on news.ycombinator.com