Hey, On Wed, Jun 3, 2009 at 9:56 AM, Shawn O. Pearce<spearce@xxxxxxxxxxx> wrote: > 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. Can someone help me out with the '.have' refs? What do they look like? Is this the same as the '.keep' ref Jakub mentioned earlier in one of the example server responses? I'm trying to take this whole thread and actually write an RFC style document for all of this stuff, but I'm still unclear on the .have portion of the conversation. Pointing me to an earlier relevant thread in the Git mailing list would be fine, too - it's difficult to search for '.have' usefully. Thanks! Scott > > 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