I think the one thing that I know GIT wins on is it's ability to "preserve line endings" on all files, whereas perforce seems to insist on translating them into either Unix, Dos/Windows or MacOS9 format ("\n", "\r\n" or "\r).
This is a real pain if you're writing Unix scripts in a Windows environment, or a mixed OS environment. It's not even possible to set the rule on a per-file-extension basis. For instance, it would convert .sh, .bash, .unix files to Unix format, and convert .ccp, .bat or .com files to Dos/Windows format.
In GIT (I'm not sure if that's default, an option or the only option) you can set it up to "preserve line endings". That means, you can manually change the line endings of a file, and then GIT will leave that format the way it is. This seems to me like the ideal way to do things, and I don't understand why this isn't an option with Perforce.
The only way you can achieve this behavior, is to mark the files as binary. As I see that, that would be a nasty hack to workaround a missing feature. Apart from being tedious to have to do on all scripts, etc, it would also probably break most diffs, etc.
The "solution" that we've settled for at the moment, is to run a sed command to remove all carriage returns from the scripts every time they're deployed to their Unix environment. This isn't ideal either, especially since some of them are deployed inside WAR files, and the sed line has to be run again when they're unpacked.
This is just something I think gives GIT a great advantage, and which I don't think has been mentioned above.
EDIT: After having been using Perforce for a bit longer, I'd like to add another couple of comments:
A) Something I really miss in Perforce is a clear and instance diff, including changed, removed and added files. This is available in GIT with the git diff command, but in Perforce, files have to be checked out before their changes are recorded, and while you might have your main editors (like Eclipse) set up to automatically check files out when you edit them, you might sometimes edit files in other ways (notepad, unix commands, etc). And new files don't seem to be added automatically at all, even using Eclipse and p4eclipse, which can be rather annoying. So to find all changes, you have to run a "Diff against..." on the entire workspace, which first of all takes a while to run, and secondly includes all kind of irrelevant things unless you set up very complicated exclusion lists, which leads me to the next point.
B) In GIT I find the .gitignore very simple and easy to manage, read and understand. However, the workspace ignore/exclude lists configurable in Perforce seem unwieldy and unnecessarily complex. I haven't been able to get any exclusions with wildcards working. I would like to do something like
-//Server/mainline/.../target/... //Svend_Hansen_Server/.../target/...
To exclude all target folders within all projects inside Server/mainline. However, this doesn't seem to work like I would have expected, and I've ended up adding a line for every project like:
-//Server/mainline/projectA/target/... //Svend_Hansen_Server/projectA/target/...
-//Server/mainline/projectB/target/... //Svend_Hansen_Server/projectB/target/...
...
And similar lines for bin folders, .classpath and .projet files and more.
C) In Perforce there are the rather useful changelists. However, assume I make a group of changes, check them all and put them in a changelist, to then work on something else before submitting that changelist. If I later make a change to one of the files included in the first changelist, that file will still be in that changelist, and I can't just later submit the changelist assuming that it only contains the changes that I originally added (though it will be the same files). In GIT, if you add a file and them make further changes to it, those changes will not have been added (and would still show in a git diff and you wouldn't be able to commit the file without first adding the new changes as well. Of course, this isn't usefull in the same way the changelist can be as you only have one set of added files, but in GIT you can just commit the changes, as that doesn't actually push them. You could them work on other changes before pushing them, but you wouldn't be able to push anything else that you add later, without pushing the former changes as well.