I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up with commits. For all the many problems in git, branches are dead easy. That was the big innovation over svn at the time.

Last time I tried jj, branches were an extremely laborious process to keep up to date. I don't see how people that aren't working alone can work with that. I have numerous branches in flight at any given time, and my colleagues do as well. The idea of manually keeping them pointed at the right commit is just nuts.

Maybe they've fixed that astonishing choice since then, and I'd give things another go if they did. But branches and worktrees are how I operate.

Regarding the article, I have no idea what is going on as I'm red-green color deficient.

> `absorb` assigns the changes based on whichever previous commit most recently touched those files, which sometimes doesn't actually correspond to which commit should own these particular changes.

I’m pretty sure `jj absorb` (and its predecessors, `git-absorb` [0] and `hg absorb`) are smarter than this, instead looking at the actual diffs.

[0]: https://github.com/tummychow/git-absorb

Or let an agent deal with any git nonsense. Yes I’m already aware some smart alec will lie about the time an agent totally deleted their entire repo and branch.

So... git rebase -i?

I'm not an expert in Magit by any means, but I bet there's a way to accomplish this in only a few keystrokes.

Since adding https://github.com/raine/git-surgeon to my workflow and installing the skill, my LLM agents haven't felt the need for anything more.

I have been walking some newer programmers through Git recently, so this topic is fresh on my mind. The commands in the blog post do not look friendlier or even different.

> For large features, I find this workflow far easier than having to maintain strict git rigour for the lifecycle of the feature's development.

I don't know about all that. All sorts of ex-post-facto automated cut-up-and-splice commits sounds to me like a recipe for an every larger mess. I say maintain git rigor, always. Now, you could say "You only say that because you know git rather than jujutsu" or "if you use git absorb more you'll get it", and theoretically you might be right, but... meh, I kind of doubt it.

So: Squash everything together then pick each component out by squash -i to an empty commit.

Seems straightforward, wouldn’t call it special

The elephant in the room is that I haven't had to do something complicated and manual in git by hand in a long while. I'm using AI to generate code, and further, having it commit to git and pushing and pulling and managing branches and merging for me.