>> 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@xxxxxxxxxxxxxxxxx/msg00032.html .... nnnope. don't understand it. at all. there's no context. http://www.mail-archive.com/gittorrent@xxxxxxxxxxxxxxxxx/msg00003.html --> http://gittorrent.utsl.gen.nz/rfc.html#anchor7 "Service Not Available". greeat. http://www.mail-archive.com/gittorrent@xxxxxxxxxxxxxxxxx/msg00023.html ah HA! +<t hangText="References:"> + + The References are the Git refs of the repository being shared. + +</t> +<t hangText="Commit reel offset:"> + + An offset into the list of all revisions sorted by their natural + topological order, their commit date and their SHA-1. + +</t> +<t hangText="Commit reel:"> + + 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. + +</t> +<t hangText="Block:"> + + A block is the actual content of a commit reel, i.e. the objects. + In Git terms, it is a pack. + +</t> 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. -- 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