On Wed, May 06, 2009 at 12:56:28PM -0700, Christopher Lee wrote: -> On May 5, 2009, at 6:42 AM, C. Titus Brown wrote: -> -> > from what I can tell: -> > -> > github maintains a history of relationships between repositories. -> > -> > If I github-fork your pygr repository into a new 'pygr' repository -> > in my -> > account, github records that fork and stores only the differences -> > between your repo and mine. -> -> Are you sure about this? Can you point me to where you got this -> explanation from github? This sounds very un-git-like to me. After -> all, each git repository is supposed to be a complete, functional -> repository (that's the D in DVCS), and merely refers to other copies -> of the repository by defining "remotes" for push / pull purposes. As -> far as I know, there is no way in git to make a "delta repository" -> that merely stores the diffs vs. a full repository stored somewhere -> else. But of course, my knowledge of git only scratches the surface -> of everything it can do...
These various options are not mutually exclusive ;). My guess is that github is using a copy-on-write approach to store the differences between repos. The fact that forks (me to you, you to me, whatever) have official relationships in the github model indicates that something special is going on. It may be as simple as metadata, as you suggest, or it may be using file links, or ... -> I thought github forks work as follows: -> -> - each repository is a normal git repository, whether it is a fork or -> not. -> -> - a fork differs from a non-fork repository in one minor way: it -> defines a remote called "upstream" that simply points to the parent -> repository. That enables the user to get updates from the parent -> repository by just saying "git pull upstream <branchname>". In all -> other respects, a fork repository is a full, normal git repository -> just like a non-fork repository. If someone were to delete the parent -> repository, I don't believe everyone's fork repositories would turn -> into pumpkins. I think the only effect would be that if a user of a -> fork repository tried to pull from the "upstream" remote, s/he'd get -> an error message saying the URL failed (because the parent repo no -> longer exists). The user would still be able to push to origin (i.e. -> the fork repo stored on github) just fine, I think, and others would -> be able to clone / pull from it just fine too. -> -> - outside the git repositories, github keeps some metadata about "who -> forked from who" to provide nice web features like pull-requests, -> network diagrams, etc. As far as I know, this is just metadata, and -> quite independent of what's actually stored in the actual git -> repositories. I agree that this could be the way github does things -- there's underlying Linux filesystem connections that git also maintains, so it may not just be a matter of metadata -- but I think the pertinent question is, can we manipulate that metadata? The rigamarole that we went through (you creating a new repo NOT forked from mine, then me deleting mine and forking from yours) would have been unnecessary had we had access to manipulate the metadata. In any case, I think we can just stick with whatever you decide. We have the proper relationships between our repositories now, and perhaps no confusion will come of it. cheers, --titus --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to pygr-dev@googlegroups.com To unsubscribe from this group, send email to pygr-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
