We still use perforce which is a mess but the reality is that you spend 2 minutes a day interacting with the tool, it doesn’t matter if it’s shit. Even now as a lead, most of my time is in swarm (reviewing), and I don’t care about all the jank that comes with P4.

I actually think git and the DVCS madness is a good example of complexity for the sake of complexity. Ending up in a detached head state through a seemingly normal series of commands, and then being able to continue working and have a very difficult resolution (compared to how you go there in the first place) that requires you to know how git works is a perfect example.

On the flip side, again in P4, you get latest and that’s it.

▲

jayd16 3 hours ago | parent | next [-]

Git's issue is not that DVCS is bad. Its just that P4 workflows work better for binaries.

Git LFS is tacked on, Git's locking support is crap, the culture of git is not to build helper plugins like P4 so no one does it.

Distributing P4 to multiple offices is a pain in the ass and it really does need a lot of hardware to keep things going.

Maybe Epic's Lore will shake things up and we get the workflow in a nicer backend. Still, sane defaults and control is also something wanted so, to your points, Lore is not a DVCS

▲

clhodapp 12 hours ago | parent | prev | next [-]

Detached head is neither scary nor hard to recover from. Heck, you don't even NEED to recover from it. You can just push you HEAD straight to a remote branch.

▲

maccard 11 hours ago | parent [-]

In order to do that you need to know what a detached head is, what head is (and when it’s something different) and that you resolve that.

It’s just not possible to end up in that state with something like P4. My current company has >1000 people, most of whom are non-technical (artists, designers) pushing every day, and even when I worked at places with 30 people, the amount of time I spent training people on “click get latest revison, and double click to submit” was absolutely dwarfed by “I followed the git setup instructions but I can’t push my changes”

▲

StilesCrisis 9 hours ago | parent [-]

In 2026 none of this matters anymore. "Claude, why can't I push my changes?" "Claude, the repo is saying something about detached HEAD, how do I fix it?"

Or even: "Claude, push the PR and sync git"--it's more than happy to take that off your plate.

▲

markus_zhang 8 hours ago | parent | next [-]

This might result in some very messy situations. I never dared to ask AI to do git for me. I did ask for help but I had to double and triple check.

Most of the time I simply remove everything and start from a clean slate.

It’s not only that. You also need to understand the concept of merge, squash merge and rebase, and the difference among them.

I admit I never dabbed into the internals because I was not very interested in git. I’m interested in other stuffs such as the OS kernel.

I do think it is the wrong tool for most people out there. If you are not doing 1,000 people distributed development there should be a different tool for source control. What my team does is 95% “one developer owns the changes of one or more files and others don’t touch them” type so it is rarely a true distributed development, in the sense of multiple people touching the same systems at the same time. However, I haven’t surveyed the landscape of version control. Maybe I should at least inspect the other big names.

▲

svnt 7 hours ago | parent | next [-]

> This might result in some very messy situations.

It doesn’t. Claude is far better and faster at this than anyone I’ve met in person. And you can work in any part of the source as though you were working alone, with all the numerous benefits of git.

Why would you not just try it on a disposable repo instead of continuing in fear? The thing about git is it is actually very very hard to do something that destroys anything because it is distributed. Make a repo. Clone it to two places. Do whatever you want including things that force push and overwrite history in origin. Then restore it from the other repo you cloned.

	▲	prmph 3 hours ago \| parent [-]
		> Clone it to two places. Failing to do this is not "very, very" hard

▲

StilesCrisis 7 hours ago | parent | prev [-]

If you haven't tried it, you're not in a position to speculate.

I have been letting Claude drive git/P4 for months and it does an impeccable job. With git in particular, it can't even screw up too bad; old hashes would save your bacon in a pinch, and they'd always be in the transcript, but it doesn't matter because Claude just doesn't struggle at this, not even a little bit.

▲

maccard 5 hours ago | parent | prev [-]

I’ve not used Claude to resolve an issue with git (I use perforce) but my experience with asking Claude to resolve p4 issues is that it goes down a huge rabbit hole and doesn’t solve the problem. I think it’s an artefact of a proprietary tool though

	▲	SleepyMyroslav 2 hours ago \| parent [-]
		I may offer anecdata on Claude and P4. I asked it to prototype some code and move what it generated into separate header and source files. In the process of doing it Claude decided to move every edited file from the workspace into its own CL. Then it noticed that something was up and tried to put everything back. I found the part of the comment from Claude suggesting that I may go recheck that it managed to put everything back to be hilarious. Just my 2c, I guess Claude is really comfy with tools that are mostly used in training and not old monster systems like P4.

▲

haileys 11 hours ago | parent | prev | next [-]

> that requires you to know how git works

Professionals should know how their tools work.

▲

maccard 6 hours ago | parent | next [-]

A few years ago I was working in a company and I posted something like this:

I am an app developer. Our front end is a C++ application (a game), our backend is a dotnet application. We also have an admin portal. A single feature, including deployment touches C#, C++, JavaScript, opentofu, AWS, windows, Linux (maybe macOS), docker, MySQL, redis, caddy, git, bash, plus all of the libraries and individual tools they call through too. Every single one of those has its own quirks and sharp edges. If I spent my working hours (40h) knowing each of those tools to a professional level, I wouldn’t have enough time to work on the app.

▲

vinyl7 6 hours ago | parent [-]

That means the application in total is way too complex, and could be pared down by orders of magnitude.

	▲	maccard 5 hours ago \| parent [-]
		It’s a backend, game and web portal that runs in a container with a database and a cache. Everything else is “incidental” complexity that just comes with running an app.

▲

markus_zhang 10 hours ago | parent | prev [-]

Can’t delete so edit out.

▲

mejutoco 9 hours ago | parent [-]

Your arguments are very confusing because of the mix of some, most, and all, and the jumping between them.

> few professionals know what ALL of the tools

> developers use (some or most)

> not all of them know

If you are a professional you need to know your tools, in any discipline. It does not matter what most or not all do. If you do not know your tools, you are not very professional.

▲

9 hours ago | parent | next [-]

[deleted]

▲

svnt 7 hours ago | parent | prev [-]

This is what argument from existential fear looks like.

▲

mecsred 6 hours ago | parent [-]

No its what basic professionalism looks like. No engineer is going to try and do the job of a PLC by manually switching 100s of electrical connections a second. The PLC is a useful tool. If you work with an engineer that tells you "I dont need to know how the system works, the PLC manages that" , theyre not going to be an engineer for very long.

	▲	svnt 6 hours ago \| parent [-]
		Sorry I meant the argument parent was responding to and confused by, not their argument. I realize it was unclear.

▲

mrkeen 11 hours ago | parent | prev [-]

Git is designed for a distributed situation. Different coders spread across time and space.

You always have the ability to try out the simple version that ignores that reality:

* Don't branch

* Always force-push to master.

▲

maccard 11 hours ago | parent [-]

Neither of those work if you work with one other person.

▲

svnt 7 hours ago | parent [-]

They work as well as perforce.

▲

maccard 6 hours ago | parent | next [-]

I disagree. Perforce requires you to be connected to the depot (ignoring reconcile offline work because that’s a break glass feature), and allows you to check in when you are not synced to latest. It forces you to deal with file level conflicts at time of update, not at the time of submission, and the intermediate state of “I have local changes that the remote/server doesn’t know about” is considered exceptional rather than the norm.

I can count on one hand the number of times I’ve had to reconcile offline work in the last 18 months, which is the equivalent of every merge commit in git.

	▲	jayd16 3 hours ago \| parent \| next [-]
		Reconcile is far heavier of an operation than a scan. You can use Git LFS locking or other side channel things to get file status tracking to work in Git but its a slog. You can usually find something for your engine of choice though.
	▲	3 hours ago \| parent \| prev [-]
		[deleted]

▲

jayd16 3 hours ago | parent | prev [-]

P4 has file locking and automatic file type locking on checkout to prevent conflicts. It honestly goes a LONG way and the games industry is built around that tooling.