On Sun, 7 May 2006 18:08:03 +1200 Martin Langhoff wrote:
> On 5/6/06, Junio C Hamano <junkio@xxxxxxx> wrote:
> > "Martin Langhoff" <martin.langhoff@xxxxxxxxx> writes:
> > >
> > > It means that for a merge or checkout involving stuff we "don't have",
> > > it's trivial to know we are missing, and so we can attempt a fetch of
> > > the missing objects or tell the user how to request them them before
> > > retrying.
> > >
> > > And in any case commits and trees are lightweight and compress well...
> >
> > Commit maybe, but is this based on a hard fact?
>
> No hard facts here :( but I think it's reasonable to assume that the
> trees delta/compress reasonably well, as a given commit will change
> just a few entries in each tree.
>
> I might try and hack a shallow local clone of the kernel and pack it
> tightly to see what it yields.
For linux v2.6.16:
7,3M commits-b41b04a36afebdba3b70b74f419fc7d97249bd7f.pack
24M commits_trees-8397f1c2a885527acd07e2caa8c95df626451493.pack
97M full-c7b2747a674ff55cb4a59dabebe419f191e360df.pack
For comparizon, a single version in packed form:
51M v2.6.12-rc2-4f3526b6815eb63da6c43ed85be1494bb776e2c5.pack
Made with
git-rev-list v2.6.16 | git-pack-objects commits
git-rev-list --objects --no-blobs v2.6.16 | git-pack-objects commits_trees
git-rev-list --objects v2.6.16 | git-pack-objects full
and this hack to git-rev-list:
diff --git a/revision.c b/revision.c
index f2a9f25..b5a929e 100644
--- a/revision.c
+++ b/revision.c
@@ -636,6 +636,10 @@ int setup_revisions(int argc, const char
revs->blob_objects = 1;
continue;
}
+ if (!strcmp(arg, "--no-blobs")) {
+ revs->blob_objects = 0;
+ continue;
+ }
if (!strcmp(arg, "--objects-edge")) {
revs->tag_objects = 1;
revs->tree_objects = 1;
So trees are definitely not lightweight, and commits are rather large
too.
Attachment:
pgpfSngLUg0nC.pgp
Description: PGP signature