I am working with Perforce for 10 years. Our repository has around 500.000 submits and our submits are either C/C++ source code or (binary) dependencies.

The lack of editor support for Perforce was always a downer. So recently I finally started evaluating Git and I enjoy the concept. I already see it's not the shiny world, but good enough to stay tuned.

So my biggest concern are dependencies. Over the entire depot lifetime we have around 200 GB of binary dependencies (new revisions, versions, etc...). The first solution is Git LFS. I made a few tests and instead of placing them in .git/objects they ended up in ./git/lfs as simple copies. My question now is, why do people still complain about Git LFS? Is that solution not good? What is the problem with Git LFS that this doesn't solve the problem git is accused of?

  • 4
    "why do people still complain about Git LFS" - citation needed.
    – Doc Brown
    Jan 11, 2020 at 8:36
  • 6
    Your question is highly unclear. You are telling us that Git LFS seems to solve the problem, but then you are asking us why it doesn't solve the problem? And you never even tell us what the problem is that you are trying to solve. As to your question "why do people still complain about Git LFS?", that is a question that only those people can answer, we can't read their minds. Jan 11, 2020 at 10:50
  • @JörgWMittag I agree my question is indeed not very clear. But that Git LFS solves and doesn't solve the problem makes absolutely sense. The goal is to cover problems with binary files, but then a lot of discussions I follow, especially about game development, where users accuse git lfs not being a real solution or being half baked. Anyway, I will update my question Jan 11, 2020 at 17:43

1 Answer 1


Git LFS is perfectly well-suited for versioning large binary assets. The problem with using git for managing dependencies isn't that git lfs can't handle it, it's that there are better solutions.

What git can't do is resolve a tree of transitive dependencies. Dependency X itself depends on version 1.x of dependency Y. There is a version 1.6 of dependency Y, but dependency Z breaks when used together with any version of Y greater than 1.4, so your system as a whole uses 1.4.

Of course, perforce can't solve that problem for you either (no common VCS can), so you've been accustomed to resolving those sorts of conflicts manually, or perhaps you've written some of your own dependency management scripts. You aren't going to lose anything by moving to git lfs, but you have a lot to gain by moving to a system like conan for dependency management.

  • Despite my indeed unclear question, thanks for the answer! That helps me a lot Jan 11, 2020 at 17:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.