Re: git pack/unpack over bittorrent - works!

From: A Large Angry SCM <gitzilla@gmail.com>
Date: Sep 2, 2010, 16:58 UTC
Message-ID: <4C7FD7A6.9090402@gmail.com>
In-Reply-To: <AANLkTikBnKQJmgOms2wK1+6fCLtHWiWkhuCVMN7kKLXP@mail.gmail.com>

On 09/02/2010 11:42 AM, Luke Kenneth Casson Leighton wrote:

Show 24 quoted lines

> On Thu, Sep 2, 2010 at 4:33 PM, A Large Angry SCM<gitzilla@gmail.com>  wrote:
>> On 09/02/2010 09:37 AM, Luke Kenneth Casson Leighton wrote:
>>>
>>> On Wed, Sep 1, 2010 at 11:04 PM, Nguyen Thai Ngoc Duy<pclouds@gmail.com>
>>>   wrote:
>>
>> [...]
>>>>
>>>> There were discussions whether a pack is stable enough to
>>>> be shared like this,
>>>
>>>   it seems to be.  as long as each version of git produces the exact
>>> same pack object, off of the command "git pack-objects --all --stdout
>>> --thin {ref}<    {objref}"
>>
>> This is not guaranteed.
>
>   ok.  greeeat.
>
>   so, some sensible questions:
>
>   * what _can_ be guaranteed?
>
>   * diffs?

Given a pre-image and a post-image, the diff/delta created will recreate the post-image from the pre-image. The bit level representation of the diff/delta is not guaranteed.

>   * git-format-patches? (which i am aware can do binary files and also
> rms)?

See above.

> * individual files in the .git/objects directory?

Uncompressed: yes. Compressed: no.

>   and, asking perhaps some silly questions:
>
> * why is it not guaranteed?

The pack format was created to move objects from one repository to another. To do that efficiently, it uses many heuristics to decide how much information is _sufficient_ to do the job but but leaves it to the implementation and user to decide the various trade offs. For instance, there is no canonical the order of the object information in a pack or that the pack must be minimal. This also allows for the multi-threaded pack implementation.

> * under what circumstances is it not guaranteed?  and, crucially, is
> it necessary to care?   i.e. if someone does a shallow git clone, i
> couldn't give a stuff.

Pretty much all of the time.

> * is it possible to _make_ the repository guaranteed to produce
> identical pack objects?

Identical code on identical systems with identical repositories without multi-threading _might_ work.

> * does for example "git gc" change the object store in such a way such
> that one git repo will produce a different pack-object from the same
> ref?  if so, can running "git gc" prior to producing the pack-objects
> gurantee that the pack-objects will be the same?

See above.

> * is it a versioning issue?  is it because there are different
> versions (2 and 3)?  if so, that's ok, you just force people to use
> the same pack-object versions.

No.

> etc. etc.
>
> l.
>