Hello Konstantin,

I've found more "git" way :)

The problem commit's SHA1 is 1e68e16e7f06868210d63bb1623b976dcedd65e4

# examine commit
$ git cat-file commit 1e68e16e7f06868210d63bb1623b976dcedd65e4
tree 06daddf0a2f63e3de1c48c2ac388811835c806ef
parent fcd7d0eaa5129f346af74c4d7e6de53c4c6e3257

# examine commit's parent
$ git cat-file commit fcd7d0eaa5129f346af74c4d7e6de53c4c6e3257
tree 72b391aca2ed1d4d625d744dc75e637cf62a5472
parent 89c46a5a69eab1360ffb30fb64ec78555650b1ab

# now we have two trees here, let's diff what changed between them
$ git diff-tree 06daddf0a2f63e3de1c48c2ac388811835c806ef 
:040000 040000 dbce387d01508f8b27617a72002db23c20d40d2e 
b83741839605467f9edbfb6ebc6271f1e90d37af M      db
:040000 040000 4fe283100c11c38d84e89f15a30dc9315ec78bc2 
1c5ab8a32cebe626e2d33be0c969a73858c0e8ef M      php

# let's see what's inside
$ git ls-tree dbce387d01508f8b27617a72002db23c20d40d2e
100644 blob 2c40b702a1f56e4814977508a2be9f76b4f236fa    2011-03-28.sql
100644 blob e555488db64750a173b9263ba015ec5ebd020722    2011-03-29.sql

# gimme filesizes
$ git cat-file -s 2c40b702a1f56e4814977508a2be9f76b4f236fa
$ git cat-file -s e555488db64750a173b9263ba015ec5ebd020722

here is size of those BIG files, and this manipulations doesn't load files in 

On Tue, 5 Apr 2011 14:41:18 +0400
Konstantin Khomoutov <flatw...@users.sourceforge.net> wrote:
KK> On Tue, 5 Apr 2011 11:23:38 +0300
KK> Artiom Di <kro...@gmail.com> wrote:
KK> > I have such commit:
KK> > 
KK> > $ git log -n1 --pretty=format:commit -m --first-parent --no-prefix
KK> > --shortstat 1e68e16e7f06868210d63bb1623b976dcedd65e4 commit
KK> >  2 files changed, 1290965 insertions(+), 5 deletions(-)
KK> > 
KK> > This operation consumes aprox 1.5Gb RAM.
KK> > The question is: how to see if some given commit is really huge
KK> > and not to load whole commit in RAM?
KK> Each commit references a tree object which, in turn, references a
KK> set of blobs and/or other tree objects referencing their own sets
KK> of blobs etc. This hierarchy of trees represents the state of your
KK> index from which a commit has been made.  IOW, "the size of a
KK> commit" is not recorded anywhere explicitly--even in tree objects,
KK> and you have to inspect the whole hierarchy of trees referenced by
KK> a commit to calculate its size. This is not really hard as Git has
KK> low-level commands to read tree objects and blobs.  On the other
KK> hand, I can't easily find any way to know the size of a blob other
KK> than using `git cat-file blob $SHA1 | wc -c`.
KK> Note also that "the size of a commit" is a vague term: I might have
KK> a one gigabyte file tracked in my repository; then I change a
KK> single byte in it and make a commit--what should really count as
KK> the size of this commit?  The change itself is only one byte, the
KK> blob representing this change is one gigabyte.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to