4 ms·

I'm with you. At least for most professional environments. It's weird. Git was made for something very specific, Linux kernel development. It made a lot of dec

I'm with you. At least for most professional environments. It's weird. Git was made for something very specific, Linux kernel development. It made a lot of decisions to support that environment. However most of us don't work in that type of environment. If you have a private repo for your job you're in a very different environment. At my job mutating history is the opposite of what I want. I don't want people mutating history. Ever! Part of the problem, in my opinion, is that Git encourages tiny commits. I might take it a step further and say that Git mandates tiny commits. Too tiny in my opinion. When that's forced upon you a clean mechanism is required. But I'm not sure it isn't sweeping another problem under the rug. But I'm weird. I'm a game developer. We all use Perforce. It just works. You can't fuck it up. You can't ruin history. You can't get stuck. Artists and designers can be trained to use it from scratch in 5 minutes. It's so easy to use there aren't tens of thousands of blog posts desperately trying to explain how easy it is use.

maccard 11y ago
> It just works. You can't fuck it up. Unless someone checks out everything in the depot by accident..
- forrestthewoods 11y ago
  We've all done that once. For most people once is enough. ;)
exDM69 11y ago
I'm from a Git background but we use Perforce at work. I wish there were blog posts desperately explaining how simple P4 is because I can't understand how to use it for software development. To me it seems like a big dump of files like a network mount with locking and some kind of history. But how the hell is one supposed to write software with it? It has complicated tools for sharing incomplete work. I don't know how you do code reviews but we have a Perl script for that(!). In other words: if you think p4 is simple and git is not, it's because of your background.
- forrestthewoods 11y ago
  I can teach an artist or designer everything they need to know about Perforce in 5 minutes. I can spend a year helping and they still won't be comfortable with Git. Every studio needs a Git expert to help people when they have a Gitastrophe. Perhaps your issue here is that P4 is too simple. You check a file in and it's there forever. Sync latest, change things, check in, voila! Once in P4 there is literally nothing you can do to permanently screw things up. Binary files are locked so only one person can edit at a time. Text files can be merged. New users may need help resolving conflicts. I recommend Araxis Merge. Code review tools always exist on top of source control. There are different tools that integrate with Git, Mercurial, SVN, Perforce, etc. What did you use at your old job that you were happy with? I do have at least some good news for you. If your company is running a semi-recent version of the Perforce server you can use Git with it. You can work 100% in Git if that's what floats your boat. https://www.perforce.com/gitswarm https://www.perforce.com/gitswarm
  - exDM69 11y ago
    The point about artists I totally get. Git isn't designed for that. But similarly I'll argue that Perforce isn't designed for programmers, or at least a group of programmers spread far and wide (geographically and/or otherwise). I'm sure even p4 works great if you're quite close to the people you share the depot with. From my point of view, Perforce is designed from completely the wrong standpoint. The "big dump of files" paradigm makes everything strange in software development. In particular, I find it needlessly difficult to share incomplete work that isn't ready to be merged (In Git, you just commit and push, in P4, you use something else, like the shelf for that). In contrast with the "big dump of files" paradigm, Git is "create patches and share them". The beauty of this is that "sharing" part works without some dedicated, blessed server and changesets are easily shared over e-mail or any other medium. I must agree with you that the Git UI is quite bad, inconsistent and not easily discoverable (ie. not something for artists). But the concepts of Git are well-defined and elegant and are thoroughly explained in the README in the first commit[0] of Git(!). To mitigate the issues with the bad UI, I've always found the Git manpages to be fairly clear and useful (but not everyone agrees). What comes to using Git client with Perforce server, I'd use it if our monorepo workflow wasn't completely incompatible with that. For me, software development has always been about creating and sharing patches, and that's why Git makes sense for me. [0] https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290 https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...

maccard 11y ago

> It just works. You can't fuck it up. Unless someone checks out everything in the depot by accident..

forrestthewoods 11y ago
We've all done that once. For most people once is enough. ;)

exDM69 11y ago

I'm from a Git background but we use Perforce at work. I wish there were blog posts desperately explaining how simple P4 is because I can't understand how to use it for software development. To me it seems like a big dump of files like a network mount with locking and some kind of history. But how the hell is one supposed to write software with it? It has complicated tools for sharing incomplete work. I don't know how you do code reviews but we have a Perl script for that(!). In other words: if you think p4 is simple and git is not, it's because of your background.

forrestthewoods 11y ago
I can teach an artist or designer everything they need to know about Perforce in 5 minutes. I can spend a year helping and they still won't be comfortable with Git. Every studio needs a Git expert to help people when they have a Gitastrophe. Perhaps your issue here is that P4 is too simple. You check a file in and it's there forever. Sync latest, change things, check in, voila! Once in P4 there is literally nothing you can do to permanently screw things up. Binary files are locked so only one person can edit at a time. Text files can be merged. New users may need help resolving conflicts. I recommend Araxis Merge. Code review tools always exist on top of source control. There are different tools that integrate with Git, Mercurial, SVN, Perforce, etc. What did you use at your old job that you were happy with? I do have at least some good news for you. If your company is running a semi-recent version of the Perforce server you can use Git with it. You can work 100% in Git if that's what floats your boat. https://www.perforce.com/gitswarm https://www.perforce.com/gitswarm
- exDM69 11y ago
  The point about artists I totally get. Git isn't designed for that. But similarly I'll argue that Perforce isn't designed for programmers, or at least a group of programmers spread far and wide (geographically and/or otherwise). I'm sure even p4 works great if you're quite close to the people you share the depot with. From my point of view, Perforce is designed from completely the wrong standpoint. The "big dump of files" paradigm makes everything strange in software development. In particular, I find it needlessly difficult to share incomplete work that isn't ready to be merged (In Git, you just commit and push, in P4, you use something else, like the shelf for that). In contrast with the "big dump of files" paradigm, Git is "create patches and share them". The beauty of this is that "sharing" part works without some dedicated, blessed server and changesets are easily shared over e-mail or any other medium. I must agree with you that the Git UI is quite bad, inconsistent and not easily discoverable (ie. not something for artists). But the concepts of Git are well-defined and elegant and are thoroughly explained in the README in the first commit[0] of Git(!). To mitigate the issues with the bad UI, I've always found the Git manpages to be fairly clear and useful (but not everyone agrees). What comes to using Git client with Perforce server, I'd use it if our monorepo workflow wasn't completely incompatible with that. For me, software development has always been about creating and sharing patches, and that's why Git makes sense for me. [0] https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290 https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...