git as some of you may know is a DVCS (Distributed Version Control system).
basically that means it can track the changes in files and organize them in a history with out the need of a central server (otherwise it would be a VCS).
what you may NOT know that that git is very different form most VCS's not JUST because it;'s distributed. it also doesn't ACTUALLY track the changes in files per-say. It tracks the changes in data.
"Semantics!" I hear you shout. and I suppose you have a point. For most use cases there is no effective difference. if all your doing is stacking one commit on top of another you'll never notice that git is tracking data not files. Heck, simple merges wont even reveal the difference.
But lest try something. say you have a folder hierarchy.
source/
data/
file1.txt
file2.txt
main/
prog.rb
and lets say you want to change the name of the top folder to src
src/
data/
file1.txt
file2.txt
main/
prog.rb
if you make this chagne and then try to commit with a VCS live subversion subversion sees 3 deleted files / 3 deleted folders and 3 new files / 3 new folders. you logs looks like this
delete source/
delete source/data
delete source/data/file1.txt
delete source/data/file2.txt
delete source/main
delete source/main/prog.rb
create src/
create src/data
create src/data/file1.txt
create src/data/file2.txt
create src/main
create src/main/prog.rb
but git sees 3 blobs of data with different names so it's log looks like this
rename source/data/file1.txt -> src/data/file1.txt
rename source/data/file2.txt -> src/data/file2.txt
rename source/main/prog.rb -> src/main/prog.rb
now svn isn't completely hopeless. SVN can be made aware of renames too. IF you use svn's rename command instead of going through your OS's normal facilities. the difference is that git can detect that rename and svn must be made explicitly aware of it
now I know that seems rather minor but the implications are huge. consider this case:
with the same hierarchy as above what if you had a branch of code working on a feature using the old folder structure. and another contribute makes the commit that renames these three files?
unless your VCS is explicitly aware of the rename how is that merge going to be clean? what if there is a series or renames and the file your working on in your branch isn't even remotely in the same place or using the same name? what if in addition to all that there have been changes (non conflicting changes normal circumstances) to this file? if you attempt to merge your branch the majority of VCS's wont have a clue what just happened and you'll have to resolve this conflict manually.
git however handles this situation just fine.
as proof I just did this exact thing (abet much more complex) with ARC's source. I changed the naming pattern of a folder, it's sub folders, and it's files to go from CamalCase to lower_case_underscores. some 210 files were affected. meanwhile I had made significant edits to some of those files in another branch. the two branches merged flawlessly without any need for manual conflict resolving.