On 09/02/2010 11:42 AM, Luke Kenneth Casson Leighton wrote:
On Thu, Sep 2, 2010 at 4:33 PM, A Large Angry SCM<gitzilla@xxxxxxxxx> 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@xxxxxxxxx>
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.
--
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