From: Jakub Narebski <jnareb@gmail•com>
To: "Shawn O. Pearce" <spearce@spearce•org>
Cc: Scott Chacon <schacon@gmail•com>,
git@vger•kernel.org, Junio C Hamano <gitster@pobox•com>
Subject: Re: Request for detailed documentation of git pack protocol
Date: Wed, 3 Jun 2009 22:19:57 +0200 [thread overview]
Message-ID: <200906032220.00238.jnareb@gmail.com> (raw)
In-Reply-To: <20090603165613.GJ3355@spearce.org>
Shawn O. Pearce <spearce@spearce•org> wrote:
> Jakub Narebski <jnareb@gmail•com> 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.
So the output (for fetch or clone) would look like this for repository
with alternates (shared object database):
00887b68fcd777f94534f0b794c5dc2e109c49938395 HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag\n
0048a6afbb5c9618395ed28a299f0913e9e6df2058ef refs/heads/adaptive-filter\n
004bbc60ab88b6899573fb545c6b4961f8ff3ce20695 refs/heads/filtered-to-window\n
003f7b68fcd777f94534f0b794c5dc2e109c49938395 refs/heads/master\n
0044226d09c3b5e16b5c1bd377aae9459cae3f778847 refs/heads/save-config\n
0050dab192738152e1fa7233e06d941f9ada865c6e65 refs/tags/jnareb@gmail•com-gpg-pub\n
00535812582f41a234828c8a2ec38047462979dc5dd8 refs/tags/jnareb@gmail•com-gpg-pub^{}\n
003c50808bc27817eac090683e44fce4368fff39f9b2 refs/tags/v1.2\n
0033b11cf09043f18b368ec0d988f064ea21247c843d .keep\n
Does it matter for fetch, or is it important only for pushing?
BTW. do "include-tag" capability MUST NOT (REQUIRED) be send if there
are not tags (tag objects?), or just SHOULD NOT (RECOMMENDED), or even
MAY NOT (OPTIONAL). GitHub server doesn't send it if there are no
tags...
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2009-06-03 20:15 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-12 21:29 Request for detailed documentation of git pack protocol Jakub Narebski
2009-05-12 23:34 ` Shawn O. Pearce
2009-05-14 8:24 ` Jakub Narebski
2009-05-14 14:57 ` Shawn O. Pearce
2009-05-14 15:02 ` Andreas Ericsson
2009-05-15 20:29 ` Linus Torvalds
2009-05-15 16:51 ` Clemens Buchacher
2009-05-14 18:13 ` Nicolas Pitre
2009-05-14 20:27 ` Jakub Narebski
2009-05-14 13:55 ` Scott Chacon
2009-05-14 14:44 ` Shawn O. Pearce
2009-05-14 15:01 ` Jakub Narebski
2009-05-15 0:58 ` A Large Angry SCM
2009-05-15 19:05 ` Ealdwulf Wuffinga
2009-06-02 21:39 ` Jakub Narebski
2009-06-02 23:27 ` Shawn O. Pearce
2009-06-03 0:50 ` Jakub Narebski
2009-06-03 1:29 ` Shawn O. Pearce
2009-06-03 2:11 ` Junio C Hamano
2009-06-03 2:15 ` Shawn O. Pearce
2009-06-03 9:21 ` Jakub Narebski
2009-06-03 14:48 ` Shawn O. Pearce
2009-06-03 15:07 ` Shawn O. Pearce
2009-06-03 15:39 ` Jakub Narebski
2009-06-03 15:50 ` Shawn O. Pearce
2009-06-03 16:51 ` Jakub Narebski
2009-06-03 16:56 ` Shawn O. Pearce
2009-06-03 20:19 ` Jakub Narebski [this message]
2009-06-03 20:24 ` Shawn O. Pearce
2009-06-03 22:04 ` Jakub Narebski
2009-06-03 22:04 ` Shawn O. Pearce
2009-06-03 22:16 ` Junio C Hamano
2009-06-03 22:46 ` Jakub Narebski
2009-06-04 7:17 ` Andreas Ericsson
2009-06-04 7:26 ` Junio C Hamano
2009-06-06 16:33 ` Scott Chacon
2009-06-06 17:24 ` Junio C Hamano
2009-06-06 17:41 ` Jakub Narebski
2009-06-03 21:38 ` Tony Finch
2009-06-03 17:11 ` Junio C Hamano
2009-06-03 19:05 ` Johannes Sixt
2009-06-03 2:18 ` Robin H. Johnson
2009-06-03 10:47 ` Jakub Narebski
2009-06-03 14:17 ` Shawn O. Pearce
2009-06-03 20:56 ` Tony Finch
2009-06-03 21:20 ` Jakub Narebski
2009-06-03 21:53 ` Tony Finch
2009-06-04 8:45 ` Jakub Narebski
2009-06-04 11:41 ` Tony Finch
2009-06-04 18:41 ` Shawn O. Pearce
2009-06-03 12:29 ` Jakub Narebski
2009-06-03 14:19 ` Shawn O. Pearce
2009-06-04 20:55 ` Jakub Narebski
2009-06-04 21:57 ` Shawn O. Pearce
2009-06-05 0:45 ` Shawn O. Pearce
2009-06-05 7:24 ` Jakub Narebski
2009-06-05 8:45 ` Jakub Narebski
2009-06-06 21:38 ` Comments pack protocol description in "Git Community Book" (second round) Jakub Narebski
2009-06-06 21:58 ` Scott Chacon
2009-06-07 8:21 ` Jakub Narebski
2009-06-07 20:13 ` Shawn O. Pearce
2009-06-07 20:43 ` Shawn O. Pearce
2009-06-13 9:30 ` Comments pack protocol description in "RFC for the Git Packfile Protocol" (long) Jakub Narebski
2009-06-07 20:06 ` Comments pack protocol description in "Git Community Book" (second round) Shawn O. Pearce
2009-06-09 9:39 ` Jakub Narebski
2009-06-09 14:28 ` Shawn O. Pearce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200906032220.00238.jnareb@gmail.com \
--to=jnareb@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=schacon@gmail$(echo .)com \
--cc=spearce@spearce$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox