Sergey Vlasov <[EMAIL PROTECTED]> writes: > All this means that currently there is no clean way to publish a partial > GIT repository, unless you place it at the same server where the base > repository is located (and even in that case needing to use something > like "echo /pub/scm/linux/kernel/git/torvalds/linux-2.6/objects > > objects/info/alternates" looks like a horrible hack).
There has never been a way to publish a partial GIT repository. I personally am not convinced it is even a good idea for people to be able to do so. $GIT_OBJECT_DIRECTORY/info/alternates is a mechanism to solve completely different issue -- borrowing objects locally from different object store to save space. This is only a local 'repository organization' issue, just like packing objects or leaving them unpacked in a repository _should_ not make any difference to people who are interacting with it. The use of info/alternates is internal to the git aware server side, be it git-daemon and git-upload-pack when somebody fetches from it, or git-receive-pack when somebody pushes into it. The other end _should_ never have to care if the repository uses info/alternates, just like it _shouldn't_ matter if the repository is packed or unpacked. Most importantly, for people who are interacting with it, the repository has _everything_ it claims to have by having pointers to head commits under refs/ hierarchy, and is _not_ partial at all. Yes, you could peek into the remote repository filesystem by other means, and even slurp the info/alternates file via rsync, but as stated many times before, a lot of things that rsync does are by accident not by design. Some historical explanation may be helpful. info/alternates is merely an improvement for existing ALTERNATE_OBJECT_DIRECTORIES mechanism. The latter required individual processes to tell git what other object stores to consult to find missing objects when working on a repository whose object store is a partial object database. This was clearly not per-process information; it was specific to that partial object store, and that was the reason info/alternates was invented. The processes do not have to have that environment variable; instead the necessary information is recorded in the partial object store itself. I kept saying '_should_' because commit walkers would not currently understand alternates, just like they had trouble with packed repositories earlier. This _is_ a defect, but I personally feel that this is a problem not worth solving. Earlier, when commit walkers did not understand packed repositories, the only workaround was 'then do not pack your public repository'. This was unacceptable from storage consumption point of view, and it had to be solved in some way. Daniel solved it for 0.99.4. But what info/alternates does is different. If you care about commit walkers (and I certainly do), there are other means to save space without using info/alternates; first try packing, and then hard linking object files with whichever other repository you would have placed in info/alternates, and you are done. Now you may argue that being able to publish truly partial repository that does not have all the objects and depends on some other repository, very likely to be on completely different server (otherwise you would not be advocating for a non-local path such as URL) a worthwhile goal. I personally do not even believe that a repository relying on a foreign object store is a good idea, and much less so if you are making that repository publicly available. I like your local-mirror-mapping idea very much, but I do not think it is something that is specific to git. If you have such a mechanism to map remote URL into local filesystem namespace and automount/mirror them on demand, I'd like to be able to use that when I am browsing files in my Emacs (yes, there is 'ange-ftp') or even 'cat' files from it. Its more useful that way than limiting its use to only when git wants to find missing object files from its alternate object store. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
