Jakub Narebski <jnareb@xxxxxxxxx> wrote: > On Wed, 3 Jun 2009, Shawn O. Pearce wrote: > > Oh, and send-pack/receive-pack protocol now has ".have" refs [...] > > What are those ".have" refs? They are not described in current version > of "Transfer Protocols" (sub)section in "The Community Book". I remember > that they were discussed on git mailing list, but I don't remember what > they were about... If the remote receiving repository has alternates, the ".have" refs are the refs of the alternate repositories. This signals to the client that the server has these objects reachable, but the client isn't permitted to send commands to alter these refs. Its good for a site like GitHub or repo.or.cz where cheap forks are implemented by creating a repository that points to a common shared base via alternates. The ".have" refs say that the server already has everything in that common shared base, so the client doesn't have to re-upload the entire project if the fork started out empty, or had all refs deleted from it. > > In packed-refs, Junio had a hard time adding the "peeled-refs" > > support, because the first version of the parser was so strict. > > But again, somehow he managed to find a backdoor in the old parser, > > and that backdoor is why that file looks the way it does today. > > I don't remember what that was about... Nevertheless now we have > kind of 'capabilities' section in .git/packed-refs Sort of. In a file format its worse than a network protocol, because the file can't alter its contents based on what the reader can understand. > Interesting... even more so that this problem of designing without > extendability in mind (magic number + version) is so persistent :-( I know. I think we maybe have learned the lesson. I don't know. -- Shawn. -- 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