I've been running some tests to see if I could find the origin of my
size-difference. As it turned out, when examining the filesystem's size on
the target with 'su', this was about 10M bigger in case of the git-cloned
filesystem (I make a jffs2-file to flash the target, thereafter examine the
target via a tty).
The entire difference could be pinned down in just 1 directory, 'sbin'.
So, I made complete listings (ls) from /sbin, both the original as the
git-cloned version. And they are exactly the same !? But with su -hs the
/sbin directory yields the 10M difference ...... ?
I do not know enough about the way Linux writes its files, and how it
determines the size of the files. But it seems to me the git-cloned files
contain empty space that occupies filesystem-space, but is not counted when
calculating the actual filesize .....
Both versions function 100% on the target, so why worry ? But I still would
like to know whats going on ....
And yes, I also used git gc (--aggressive), but this yields no improvement
at the client side upon cloneing/checking out.
To be continued ....
> My guess is that the cloned repository isn't compressed in exactly the
> same way as the original repository.
> The first step would be to find out the amount of disk space occupied
> by the original and the cloned repositories (using "du -s") rather
> than depending on the size of the .tar files.
> If you want the repository to be small, look into "git gc
> Dale Worley
> Today is: 126.96.36.199.0 9 Ahaw 18 Mak
> Only 1100 more shopping days until the end of the World.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.