Subject: Re: git pack/unpack over bittorrent - works!

From: A Large Angry SCM <[email-masked]>
Date: Thu, 02 Sep 2010 13:06:32 -0400

On 09/02/2010 11:51 AM, Luke Kenneth Casson Leighton wrote:
> On Thu, Sep 2, 2010 at 4:42 PM, Luke Kenneth Casson Leighton
> <[email-masked]>  wrote:
>> On Thu, Sep 2, 2010 at 4:33 PM, A Large Angry SCM<[email-masked]>  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?

No. Looking to use identical packs created on different systems is not 
something that git guarantees or, likely, will ever guarantee. If you 
need that, you need to create and implement the canonical pack-like 
definition for your transfer protocol.

>   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?

Write your own "packer" is really the best answer.

> 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.

Sounds ugly and inefficient.