True to some extent. (Large files I will agree with.) That wasn't his only argument: the other was about large repos. I've seen many places try to attempt a 1:1 conversion of a Perforce depot to a git repository, and this will likely not work well: the Perforce depots are simply too large. A Perforce depot typically, in my experience, contains the entire source code for the entire company. A Git repository would be suitable for a subtree in that depot that represents a logical project, often managed by a team of related co-workers. So one Perforce depot would correspond to multiple git repos; however, like I said, I feel like people try to shoehorn the entire depot into a single repo.

The downside is you have multiple repos, whereas before you had a single large repo, and any cross git-repo changes would be made in a single changelist. In git, you'll need multiple commits, and some way to manage inter-repo dependencies in those changes. (Such as semantic versioning, and a decent build system.)

The downside of Perforce that I ran into while working with it is that it lacks git's branching model, many of git's day-to-day conveniences (I so miss git add -p, git commit for just pushing out small fixes that either don't need review or for which review is trivial), and frankly, the fact that a commit hash represents a set state. (Between creation of a changelist, running tests, and submitting the changelist, someone can break you; this is not possible in git, as the push will fail.)

In the long run, I greatly prefer the extra management work of git for the power it brings with its branching model.

> I don't think he was that negative.

> > Most grownup software shops use Perforce

In my reading of this, there is an insinuation that shops using git are not "grownup"; I would call this disrespectful, myself.