Re: [tlug] Poll: OpenOffice or LibreOffice?

[Darren Cook <darren@example.com>]

>> Git hashes each file (that exists now, or has existed in the past), and
>> creates one file per hash code.
> 
> To be clear: there is no copy of the actual files, right?

Unless I've misunderstood, there is a copy. (It might be zipped, in
which case my below numbers are off.) Otherwise when you delete your
file, going back in the git history wouldn't be able to recover it.

> Practical example: someone has a disk 90% full of music, pics, and
> video. No space
> anywhere else. Will git need another disk, just to find dups?

Git is the wrong tool for that (IMHO). Go straight to md5 hashes.

>> (So it can detect duplicates in the directory tree; but you could
>> achieve the same by just writing a script to run md5sum on every file.)
> 
> This was my initial question (and my solution). I just wondered if git
> could do the same
> with 2 lines instead of my 100 :)

I bet someone with more bash skills than me could make it a one-liner.
Something like:
  find . | xargs md5sum | sort | uniq

Er, or something like that.

>> Personally I don't do that, and just back it all up, .git/ and all. It
>> means I'm backing up roughly 2.5GB for every 1GB of real files. ...

> The 2.5 for 1 ratio is due to what exactly? 

+1 for a full copy of the initial files. Then I'm guessing most of the
other files don't change much. But, better to get some hard facts. Here
is one directory (a web app) with 3191 git log entries:

112MB in total, and .git is 26MB of that. I see roughly 30MB is being
excluded by .gitignore. So:
   56MB real files gives a 26MB git directory.

Much less than by 2.5 ratio. This could well be compression. Or me
misunderstanding how git works.

Darren


-- 
Darren Cook, Software Researcher/Developer
My new book: Data Push Apps with HTML5 SSE
Published by O'Reilly: (ask me for a discount code!)
  http://shop.oreilly.com/product/0636920030928.do
Also on Amazon and at all good booksellers!