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 72b391aca2ed1d4d625d744dc75e637cf62a5472 :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 1413913689 $ git cat-file -s e555488db64750a173b9263ba015ec5ebd020722 1403540620 here is size of those BIG files, and this manipulations doesn't load files in RAM. 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> 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 git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
