From: Luke Kenneth Casson Leighton Date: Thu, 02 Sep 2010 13:53:54 GMT Subject: Re: git pack/unpack over bittorrent - works! Message-ID: In-Reply-To: >> one of the reason "commit reel" was introduced. > >  ah _ha_.  i need to look that up.  will get back to you. > >  l. > http://www.mail-archive.com/gittorrent@lists.utsl.gen.nz/msg00032.html .... nnnope. don't understand it. at all. there's no context. http://www.mail-archive.com/gittorrent@lists.utsl.gen.nz/msg00003.html --> http://gittorrent.utsl.gen.nz/rfc.html#anchor7 "Service Not Available". greeat. http://www.mail-archive.com/gittorrent@lists.utsl.gen.nz/msg00023.html ah HA! + + + The References are the Git refs of the repository being shared. + + + + + An offset into the list of all revisions sorted by their natural + topological order, their commit date and their SHA-1. + + + + + A commit reel consists of two commit reel offsets, and all the objects + that are reachable from the revisions between the two offsets, but + not the revisions after the second offset. In Git terms, a commit + reel is a bundle. + + + + + A block is the actual content of a commit reel, i.e. the objects. + In Git terms, it is a pack. + + oh - right.... so, translating that: the concern is not that the git pack-objects might be different (could someone pleaaaase confirm that!) - the concern is that the order of _unpacking_ *has* to be done in the specific order in which they were (originally) committed. if that's all it is, then yes, i thought that that was plainly obvious, and had taken it into consideration already, by creating a virtual file which contains the order of the commits. this is achieved merely by making the contents of "git rev-list" available. voila, dead-simple: you now have enough information to be able to apply the pack objects in the right order. l.