Re: git pack/unpack over bittorrent - works!
- From
- Luke Kenneth Casson Leighton <luke.leighton@gmail.com>
- Date
- Sep 2, 2010, 15:51 UTC
- Message-ID
- <AANLkTi=W3QwWSrNTie-K4QDDrucSVGQa5e3Ldy7m7ihy@mail.gmail.com>
- In-Reply-To
- <AANLkTikBnKQJmgOms2wK1+6fCLtHWiWkhuCVMN7kKLXP@mail.gmail.com>
On Thu, Sep 2, 2010 at 4:42 PM, Luke Kenneth Casson Leighton <luke.leighton@gmail.com> wrote:
> On Thu, Sep 2, 2010 at 4:33 PM, A Large Angry SCM <gitzilla@gmail.com> wrote:
> * is it possible to _make_ the repository guaranteed to produce > identical pack objects?
i.e. looking at these options, listed from Documentation/technical/protocol.txt:
00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag
is it possible to use shallow, thin-pack, side-band or side-band-64k to guarantee that the pack object will be identical?
another important question:
* if after performing a "git unpack" of one pack-object, can it be guaranteed that performing a "git pack-object" on the *exact* same ref and the *exact* same object-ref, will produce the *exact* same pack-object that was used by "git unpack", as long as the exact same arguments are used? if not, why not, and if not under _some_ circumstances, under what circumstances _can_ the exact same pack-object be retrieved that was just used?
if there is absolutely absolutely no way to guarantee that the pack-objects can be the same, under no circumstances or combinations of arguments or by forcing only compatible versions to communicate etc. etc., a rather awful work-around can be applied which is to share and permanently cache every single pack-object, rather than use what's gone into the repo.
l.