On Wed, Dec 1, 2010 at 2:08 AM, Martijn van Oosterhout <klep...@svana.org> wrote: > On Wed, Dec 01, 2010 at 01:03:26AM -0500, Tom Lane wrote: >> So I just made a commit that touched four files in all six active >> branches, and I see: >> >> $ git push >> Counting objects: 172, done. >> Compressing objects: 100% (89/89), done. >> Writing objects: 100% (89/89), 17.07 KiB, done. >> Total 89 (delta 80), reused 0 (delta 0) >> To ssh://g...@gitmaster.postgresql.org/postgresql.git >> 35a3def..8a6eb2e REL8_1_STABLE -> REL8_1_STABLE >> cfb6ac6..b0e2092 REL8_2_STABLE -> REL8_2_STABLE >> 301a822..0d45e8c REL8_3_STABLE -> REL8_3_STABLE >> 61f8618..6bd3753 REL8_4_STABLE -> REL8_4_STABLE >> 09425f8..0a85bb2 REL9_0_STABLE -> REL9_0_STABLE >> c0b5fac..225f0aa master -> master >> >> Now I realize that in addition to the four files there's a "tree" object >> and a "commit" object, but that still only adds up to 36 objects that >> should be created in this transaction. How does it get to 172? And >> then where do the 89 and 80 numbers come from? > > IIRC, each directory also counts as an object. So if you change a file > in a/b/c/d you get 5 commit objects, one for the file and four for the > directories.
No, not 5 commit objects - 5 trees (for the directories, including the root directory), 1 blob (for the file), and 1 commit. From gIt(1): The object database contains objects of three main types: blobs, which hold file data; trees, which point to blobs and other trees to build up directory hierarchies; and commits, which each reference a single tree and some number of parent commits. So in Tom's case I think we can account for the root directory, src, src/backend, src/backend/executor, src/backend/optimizer, src/backend/optimizer/util, src/test, src/test/regress, src/test/regress/expected, src/test/regress/sql, the 4 files actually updated, and the commit - 15 objects per branch * 6 branches = 90 objects. I'm not sure why the actual number is 89, unless perhaps two of the post-commit regression test files were byte-for-byte identical and got collapsed into a single object. I believe that "delta" refers to the number of those objects that are stored as deltas against an existing object (in essence, diffs) rather than as completely new copies. I have no idea where the 172 number comes from. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers