If I have a file or directory that is a symbolic link and I commit it to a git repo what happens to it?
I would assume that it leaves it as a symbolic link until the file is deleted and then if you pull the file back from an old version it just creates a normal file.
What does it do when I delete the file it references? Does it just commit the dangling link?
git just stores the contents of the link (i.e. the path of the file system object that it links to) in a 'blob' just like it would for a normal file. It then stores the name, mode and type (including the fact that it is a symlink) in the tree object that represents its containing directory.
When you checkout a tree containing the link, it restores the object as a symlink regardless of whether the target file system object exists or not.
If you delete the file that the symlink references it doesn't affect the git-controlled symlink in any way. You will have a dangling reference. It is up to the user to either remove or change the link to point to something valid if needed.
Symlinked directories:
It's important to note what happens when there is a directory which is a soft link. Any git pull with an update removes the link and makes it a normal directory. This is what I learnt hard way. Some insights here and here.
Example
Before
ls -l
lrwxrwxrwx 1 admin adm 29 Sep 30 15:28 src/somedir -> /mnt/somedir
git add/commit/push
It remains the same
After git pull AND some updates found
drwxrwsr-x 2 admin adm 4096 Oct 2 05:54 src/somedir
More on symlinked directories:
It's worth noting that Pythonic's warnings about symlinked directories do not apply to versioned symlinks. The major edge case in question was that of folks symlinking some or all of the working tree into a different path (say onto a different partition with more disk space) and expecting git to check out code through the existing symlink.
That is, if you have a project that contains versioned symlinks to files or directories, the normal symlink-as-blob behavior will preserve symlinks, correctly version changes to those symlinks, and otherwise work as expected.
The above behavior tested with git 1.6.5.6; but I strongly suspect that versioned behavior has been correct in git for quite some time.
if you want to include the files within a symlinked directory, consider the "mount --bind" trick: http://stackoverflow.com/questions/86402/how-can-i-get-git-to-follow-symlinks/2079380#2079380