Hi Dale,

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 ....

Regards,

Peter
 

> 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 
> --aggressive". 
>
> Dale 
>
> Dale Worley 
> -- 
> Today is:  12.19.16.17.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 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to