On 2008/2/23, Charles Bailey <charles@xxxxxxxxxxxxx> wrote:
> You're confusing two things together here. Conceptually, the git
> database is a database of immutable objects. How it is stored is a
> lower level implementation detail (albeit a very important one in
> practice). The delta chains in the pack files are nothing to do with
> git objects.
In Documentation/git-repack.txt says:
git-repack is used to combine all objects that do not currently
reside in a "pack", into a pack. It can also be used to re-organize
existing packs into a single, more efficient pack.
A pack is a collection of objects, individually compressed, with
delta compression applied, stored in a single file, with an
associated index file.
### Can you explain me that delta chains in the pack files are
nothing to do with git objects? ###
Packs are used to reduce the load on mirror systems, backup engines,
disk storage, etc.
> You seem to be comparing something that I've said with something that
> you said. Originally I thought that you were making a bandwidth
> argument, now you seem to be making a repacking time argument. Is X
> supposed to represent to second cloned repository?
Yes, X is as the 2nd cloned repository but highly repacked, same size is not.
>
> If you git clone with --reference or git fetch from a non-dumb source
> repository then the remote end will generate a packfile of just the
> objects that you need to update the local repository. If the remote
> side is fully packed then A can reuse the delta information it already
> has to generate this pack efficiently. On the local side, there is no
> need to unpack these objects at all. The pack can just be placed in
> the repository and used as as.
Is not it redundant to place git objects and pack files in the same repo?
1. Or erase the unnecesary pack files because there are git objects.
2. Or erase some git objects because there are delta chains in pack files
that can generate the same git objects erased previously.
> What do you mean by 'the eternal repacking 24/365'? What is it trying
> to achieve?
It's an uninterrumpted computing that is generating a sequence of
spanning trees in convergence to smaller packs.
Each smaller spanning tree is found, the pack file is updated.
> What is the weekly user? Why would the 'binary delta' be better than
> an incremental pack in this case?
Because the user wants to clone weekly 240 MiB in 1st week, 220 MiB in
2nd week, 205 MiB in 3rd week, .... 100 MiB repo! in Nth week instead of
240+1+1+1+1 MiB of incremental packs.
What is better for the user in the Nth week, 100 MiB repo or 244 MiB repo?
;)
-
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
