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.

> 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.

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.