3 ms·
Git has some serious disadvantages when compared to a centralized VCS like Perforce. It just can't handle anything more than 10~15 million lines of code (this i
by artagnon 11y ago
Git has some serious disadvantages when compared to a centralized VCS like Perforce. It just can't handle anything more than 10~15 million lines of code (this is the size of linux.git).
In a way, Perforce is a cute middle ground. It has "pending changelists" that ReviewBoard or Phabricator can slurp up and present to reviewers. You can easily give another person your changes by "shelving" them. Mutable history is only really a "feature" in tiny projects; in massive ones, immutability simplifies life greatly and restores peace of mind. In many ways, the way Perforce handles conflicts is nicer: it doesn't pollute the actual files with conflict markers, and has an option to resolve conflicts in a nice 3-pane UI. Although it does get merges wrong every now and then.
Non-linear history is considered an "anti-feature" by many, and the LLVM community runs a primary SVN server; users submit via git-svn.
Having cheap and lightweight branching is what leads to merge headaches. In fact, (from one Tech Talk), I believe that Google runs a single branch to evade merge problems altogether.
I think git's greatest asset is the excellent local development experience. You can muck around as much as you like, making local branches/commits as checkpoints, and squash them in to submit a final patch. The command-line UI is fantastic, and everything is snappy (provided you have a small checkout). I think having a single linear "trunk" on the server-side is a good idea.
- pmiller2 11y ago> Non-linear history is considered an "anti-feature" by many, and the LLVM community runs a primary SVN server; users submit via git-svn. > Having cheap and lightweight branching is what leads to merge headaches. In fact, (from one Tech Talk), I believe that Google runs a single branch to evade merge problems altogether. Running a single branch also gets rid of the nonlinear history problem. We do it where I work and it works great. Every developer submits PRs from feature branches on their forked copy of the main repo, which get merged in after review and testing. At any time, we can roll back to the previously deployed version of prod if we have to. Mutable history is also nice for these forked repos, since it allows us to squash commits and eliminate any wrong turns we take in the development process, leaving the main repo's history cleaner.
- setpatchaddress 11y agoPerforce is expensive garbage designed by mainframe programmers. The command line tool had the worst UI of any VCS I've ever used.
- HappyTypist 11y agoCorrection: Google runs a single repo with everything from Search to Gmail, not a single branch.