On 9/8/06, Junio C Hamano <junkio@xxxxxxx> wrote:
[*4*] In git, there is no inherent server vs client or upstream vs downstream relationship between repositories. You may be even fetching from many people and do not have a set upstream at all. Or you are _the_ upstream, and your notebook has the latest devevelopment history, and after pushing that latest history to your mothership repository, you may decide you do not want ancient development history on a puny notebook, and locally cauterize the history on your notebook repository and prune ancient stuff. The objects missing from the notebook repository are retrievable from your mothership repository again if/when needed and you as the user would know that (and if you are lucky you may even remember that a few months later), but git doesn't, and there is no reason for git to want to know it. If we want to do "fault-in on demand", we need to add a way to say "it is Ok for this repository to be incomplete -- objects that are missing must be completed from that repository (or those repositories)". But that's quite a special case of having a fixed upstream.
A 'not-present' object would be a normal git object, it would contain a list of sha1s that it is stubbing for. These alias sha1s need to end up somewhere where the git tools can find them. Maybe put all of the 'not-present' objects into their own pack and add the aliases to the index. If the aliases point back the 'not-present' object everything can be validated even if the alias sha1s don't match the one of the object. This pack would be private and not sent to other repositories. It would be useful to maintain a list of possible remote repositories to search for the missing objects if needed. This list could be shared with people that clone from you. If you clone from a remote repository that is a partial copy you may not be able to get all of the objects you want. The only choice here is to point them to 'not-present' stub and try searching the alternative repository list. If you really want to build something for the future, have all of the git repositories on the net talk to each other and use a distributed hash scheme to spread redundant copies of the objects out over the cloud of servers. This will have the effect of creating a global namespace for all git projects. -- Jon Smirl jonsmirl@xxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html