3 ms·

I remember using Perforce and Accurev about 10 years ago, and they were miles better than Git in terms of abstraction and feature set. I often miss being able t

by mihaic 3y ago

I remember using Perforce and Accurev about 10 years ago, and they were miles better than Git in terms of abstraction and feature set. I often miss being able to work on multiple branches with partially uncommitted local work for instance. I do want the open-source world to improve and if we merely build on top of git's abstraction, how can we have any progress then?

haradion 3y ago
For the specific use case you're describing, I've found `git worktree` to be very useful. Overall, at least when it comes to features, I've actually had the opposite experience. That said, I'm one of those people such that you can pry `git rebase` out of my cold, dead hands, so it's that feature specifically that I really miss when I have to work with Perforce.
- deleted 3y ago
  [deleted]
ubertaco 3y ago
Salesforce uses Perforce internally, and it's a _massive_ source of problems for their giant monorepo precisely because there's no lightweight branching, so among the 1500+ developers working on the same codebase, _someone_'s always checking broken crap into the same branch all the time and causing huge headaches for everyone else. When I left, they were investing a ton of time and developer hours into trying to duct-tape git onto their workflow by having smaller groups of developers share cached copies of their huge Perforce repo, and shunting the inevitable merge conflicts onto someone else and hoping for the best. I spent a considerable amount of time training folks at my acquisition how to work in this environment, and roughly 70% of that time was "yes, Perforce _is_ weird and confusing and annoying, and yes, it _would_ be better if we had lightweight branches, but instead we're stuck in the version-control stone age of Perforce, so here's the complex process you can try to go through to un-break your own local codebase temporarily until someone else has fixed the broken crap they checked in."

by mihaic 3y ago

haradion 3y ago

For the specific use case you're describing, I've found `git worktree` to be very useful. Overall, at least when it comes to features, I've actually had the opposite experience. That said, I'm one of those people such that you can pry `git rebase` out of my cold, dead hands, so it's that feature specifically that I really miss when I have to work with Perforce.

deleted 3y ago
[deleted]

ubertaco 3y ago

Salesforce uses Perforce internally, and it's a _massive_ source of problems for their giant monorepo precisely because there's no lightweight branching, so among the 1500+ developers working on the same codebase, _someone_'s always checking broken crap into the same branch all the time and causing huge headaches for everyone else. When I left, they were investing a ton of time and developer hours into trying to duct-tape git onto their workflow by having smaller groups of developers share cached copies of their huge Perforce repo, and shunting the inevitable merge conflicts onto someone else and hoping for the best. I spent a considerable amount of time training folks at my acquisition how to work in this environment, and roughly 70% of that time was "yes, Perforce _is_ weird and confusing and annoying, and yes, it _would_ be better if we had lightweight branches, but instead we're stuck in the version-control stone age of Perforce, so here's the complex process you can try to go through to un-break your own local codebase temporarily until someone else has fixed the broken crap they checked in."