3 ms·

Why I agree with many points you make... let's keep Perforce out of it. The amount of damage that program done to my source code, and the amount of pain caused

Why I agree with many points you make... let's keep Perforce out of it. The amount of damage that program done to my source code, and the amount of pain caused by it in daily use tells me that 10 minutes will not cut it. Here's a simple example of how people shoot themselves in the foot with Perforce all the time: it makes files you edit read-only, and then you run with your pants on fire trying to figure out how to save your changes, because the system won't let you do that. And then you do something dumb, like copy the contents of the file you aren't able to save someplace else, and then try to incorporate those changes back once you've dealt with the file that Perforce wouldn't save. And then end up with a merge conflict just working with your one single change that you are trying to add to your branch. I never regretted never having to touch Perforce ever again. Just no.

maccard 2y ago
Why does git get a free pass for shitty defaults but perforce doesn’t? Perforce long predates git, and the checkout operation (which can be done on save with any modern editor) fixes that immediately.
- jayd16 2y ago
  Have you actually used P4 in anger? Having to add P4 support to any script, sucks. Having to do a network operation when touching files, sucks. Many many many apps have no idea what p4 is and will never get p4 support. Git gets out of the way.
  - maccard 2y ago
    > Have you actually used P4 in anger? Yes. I use it every day. I've ran P4 servers that serve hundreds of GBs per day globally with both commit edges and regular proxies. I've written batch scripts, bash scripts, and tooling in python, go and C# around it. > Having to add P4 support to any script, sucks. I disagree. It's no worse than adding git support to something. p4 zTag isn't the most elegant thing, but it works. > Having to do a network operation when touching files, sucks. Does it? Is it any worse than having to keep the entire history of every file locally on your machine, including any "large files?" And git-lfs as a solution to that means you're now coupled to wherever those files are stored. Making large submits to P4 isn't the nicest experience, but it sure beats paying that price every time you clone a repo IMO. > Many many many apps have no idea what p4 is and will never get p4 support In the same way that many people in this thread are blaming a git gui for a problem, "that's not P4's fault". I do agree it's shit though. > Git gets out of the way. Until it doesn't.
    - jayd16 2y ago
      The point is you don't need to add git support. Yes, network traffic does suck more than spending extra disk space, especially when you need multiple workspace because P4 sucks at switching anyway. I don't understand what you mean about cloning. If you set up LFS properly it's not much worse than a fresh P4 pull.
forrestthewoods 2y ago
You could have marked the file as not read-only and later reconciled. Or you could have checked the file out of Perforce. You would have had a merge conflict either way. I mean I haven't even talked about how Git can't handle large files. And no Git LFS doesn't count. And Git doesn't even pretend to have a solution to file locking. I'm not saying Perforce is perfect. There's numerous things Git does better. But Perforce is exceedingly simple to teach someone. And it doesn't require a 193 page guide. I can teach artists and designers how to use Perforce and not lose their work. A senior engineer who is a Git expert can still shoot themselves in the foot and get into really nasty situations they may or may not be able to get out of. There's a reason that like 105% of AAA game dev uses Perforce.
- crabbone 2y ago
  So, there's a difference between how problems are common, how many of them are there, and how hard it is to deal with them. So, is it possible to deal with Perforce marking files read-only? -- Yes. And it's not complicated, but the whole idea that that how the system should work is stupid. The problem is, however, exceptionally common. In my days working with Perforce there hadn't been a day when this problem didn't rear its ugly head. So, maybe Perforce is scoring better on some metric, but in the day-to-day it generates so much hatred towards itself that I don't care if it can handle big files better than Git does. I only need to handle big files maybe a few times a year. And I prefer to get frustrated only twice or three times a year than to be fuming every time I have to touch files in my project.
  - forrestthewoods 2y ago
    I appreciate your hatred of Perforce. But I think you've let your hatred blind yourself to the argument I actually made. In my original comment I made two arguments: 1. Git is complicated 2. Perforce is so simple to use that I can teach an artist or designer who has never even heard of source control how to use it in 10 minutes. Then you came in and said the way Perforce handles read-only files is stupid. You know what, I agree! That's a solvable problem. If Perforce wasn't acquired by a private equity firm maybe they'd actually work to make it better. Alas. This isn't about Git vs Perforce. I post in all of these Git HN threads because I desperately want people to realize that Git sucks ass and is actually really bad. WE COULD HAVE SOURCE CONTROL THAT DOESN'T SUCK. IT'S POSSIBLE. I'm not saying that Perforce is that solution. I'm saying that Mercurial and Perforce are existence proofs that certain things are possible. Source control doesn't have to be complicated! It doesn't have to have footguns! It doesn't need a 189 page guide!

maccard 2y ago

Why does git get a free pass for shitty defaults but perforce doesn’t? Perforce long predates git, and the checkout operation (which can be done on save with any modern editor) fixes that immediately.

jayd16 2y ago
Have you actually used P4 in anger? Having to add P4 support to any script, sucks. Having to do a network operation when touching files, sucks. Many many many apps have no idea what p4 is and will never get p4 support. Git gets out of the way.
- maccard 2y ago
  > Have you actually used P4 in anger? Yes. I use it every day. I've ran P4 servers that serve hundreds of GBs per day globally with both commit edges and regular proxies. I've written batch scripts, bash scripts, and tooling in python, go and C# around it. > Having to add P4 support to any script, sucks. I disagree. It's no worse than adding git support to something. p4 zTag isn't the most elegant thing, but it works. > Having to do a network operation when touching files, sucks. Does it? Is it any worse than having to keep the entire history of every file locally on your machine, including any "large files?" And git-lfs as a solution to that means you're now coupled to wherever those files are stored. Making large submits to P4 isn't the nicest experience, but it sure beats paying that price every time you clone a repo IMO. > Many many many apps have no idea what p4 is and will never get p4 support In the same way that many people in this thread are blaming a git gui for a problem, "that's not P4's fault". I do agree it's shit though. > Git gets out of the way. Until it doesn't.
  - jayd16 2y ago
    The point is you don't need to add git support. Yes, network traffic does suck more than spending extra disk space, especially when you need multiple workspace because P4 sucks at switching anyway. I don't understand what you mean about cloning. If you set up LFS properly it's not much worse than a fresh P4 pull.

forrestthewoods 2y ago

You could have marked the file as not read-only and later reconciled. Or you could have checked the file out of Perforce. You would have had a merge conflict either way. I mean I haven't even talked about how Git can't handle large files. And no Git LFS doesn't count. And Git doesn't even pretend to have a solution to file locking. I'm not saying Perforce is perfect. There's numerous things Git does better. But Perforce is exceedingly simple to teach someone. And it doesn't require a 193 page guide. I can teach artists and designers how to use Perforce and not lose their work. A senior engineer who is a Git expert can still shoot themselves in the foot and get into really nasty situations they may or may not be able to get out of. There's a reason that like 105% of AAA game dev uses Perforce.

crabbone 2y ago
So, there's a difference between how problems are common, how many of them are there, and how hard it is to deal with them. So, is it possible to deal with Perforce marking files read-only? -- Yes. And it's not complicated, but the whole idea that that how the system should work is stupid. The problem is, however, exceptionally common. In my days working with Perforce there hadn't been a day when this problem didn't rear its ugly head. So, maybe Perforce is scoring better on some metric, but in the day-to-day it generates so much hatred towards itself that I don't care if it can handle big files better than Git does. I only need to handle big files maybe a few times a year. And I prefer to get frustrated only twice or three times a year than to be fuming every time I have to touch files in my project.
- forrestthewoods 2y ago
  I appreciate your hatred of Perforce. But I think you've let your hatred blind yourself to the argument I actually made. In my original comment I made two arguments: 1. Git is complicated 2. Perforce is so simple to use that I can teach an artist or designer who has never even heard of source control how to use it in 10 minutes. Then you came in and said the way Perforce handles read-only files is stupid. You know what, I agree! That's a solvable problem. If Perforce wasn't acquired by a private equity firm maybe they'd actually work to make it better. Alas. This isn't about Git vs Perforce. I post in all of these Git HN threads because I desperately want people to realize that Git sucks ass and is actually really bad. WE COULD HAVE SOURCE CONTROL THAT DOESN'T SUCK. IT'S POSSIBLE. I'm not saying that Perforce is that solution. I'm saying that Mercurial and Perforce are existence proofs that certain things are possible. Source control doesn't have to be complicated! It doesn't have to have footguns! It doesn't need a 189 page guide!