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.