Re: Change set based shallow clone

From: Jon Smirl <jonsmirl@gmail.com>
Date: Sep 8, 2006, 14:20 UTC
Message-ID: <9e4733910609080720s7a143d9bp5a1dd36869967c22@mail.gmail.com>
In-Reply-To: <7vac5ancvo.fsf@assigned-by-dhcp.cox.net>

On 9/8/06, Junio C Hamano <junkio@cox.net> wrote:

Show 18 quoted lines

> [*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@gmail.com