3 ms·
That is nice, but it makes me wonder how little people actually know and use git nowadays. This is after all, something git really shines at. Still good to se
by freedomben 1y ago
That is nice, but it makes me wonder how little people actually know and use git nowadays. This is after all, something git really shines at. Still good to see! (It's not like I can't still just use git for that, which I fully intend to do)
- lupusreal 1y agoFor the first few hours of using claude code, I was really excited about finally not being too lazy to commit often because cc would do it for me. But then I hit my pro account limit and I realized that I'd rather spent my tokens writing features instead of commits... I should probably upgrade my account.
- gregable 1y agoThere's value in rewinding both the code and the prompt to the some point in time.
- lihaciudanieljr 1y ago[dead]
- epiccoleman 1y agoThat was my first thought too - but this is subtly different, and rewinds the context too. Actually highly useful, because I have often felt like a bad first pass at a solution poisoned my context with Claude.
- freedomben 1y agoAh, thank you, that's a great sublety that I missed before!
- anjimito 1y agoYeah this is definitely a useful feature. I use git add for good passes, but this eliminates more manual work
- ed_mercer 1y agoIf you're building a feature, you don’t want to commit every single line of code. Instead, you commit complete chunks of work. That’s why the ability to go back with Esc-Esc and revert code changes when Claude goes off the rails is a very welcome improvement.
- zahlman 1y agoIf you're using AI like this, it seems to me that it would be perfectly reasonable to make a separate branch, allow for micro-commits, and squash once a "complete chunk of work" is done. That said, having a single option that rewinds LLM context and code state is better than having to do both separately.
- fragmede 1y agoUgh, no. Git is a distributed vcs. Changes in git stay local unless and until you push them to a server, and then furthermore, point someone else at your changes for review. (Formal PR or otherwise.) Your tools should work for you, and git is no exception. Commit early and commit often. Before you (or an LLM) go on a jaunt through the code, changing whatever, commit the wip to git as you go along. That way, if something goes awry, it's an easy git reset HEAD^ to go backwards just a little bit and undo your changes. Later on, when it's time to share your work, git rebase -i main (or wherever your branching off point was). This will bring up your editor with a list of commits. Reorder them to make more sense, and then also merge commits together by changing the first word on the line to be "fixup". exit your editor and git will rewrite history for outside consumption. Then you can push and ask someone else to review your commits, which hopefully is now a series of readable smaller commits and not one giant commit that does everything, because those suck to review.
- stavros 1y agoI know and use git (well, Jujutsu, which is even better), but it's a right pain to figure out the time of each message and rewind to that exact point. The additional convenience is very much appreciated.
- torben-friis 1y ago- you DONT want your personal Claude conversation in your repo - you DO want your prompts and state synced (going back to a point in the prompt <=> going back to a point in the code). Git is a non starter then. At least the repo’s same git. Plus, you probably don’t want the agent to run mutating git commands, just in case it decides to allucinate a push —force