[eru]

> [...] where there is no good way to make the whole bundle atomic.

You could just do all the commit manipulations you need to do, and only update the branches at the very end?

Updating the individual branch 'pointers' ain't atomic, but if there's nothing else going on in the repo at the time, it can't really fail; if you've already created the new commits.

[sanderjd]

When things like this usually go wrong with an automated tool, it's not that it "fails", it's that it succeeds part of the way, leaving things in an inconsistent state, which is then hard to reconstruct in either direction.

But you're right that it should be possible to build such things in a way that works well and very rarely screws up. But just that I don't really know of any tools that try to do anything more complicated than `rebase -i` seems to suggest that it is not easy to do, or there would be more people doing this.

[eru]

> When things like this usually go wrong with an automated tool, it's not that it "fails", it's that it succeeds part of the way, leaving things in an inconsistent state, which is then hard to reconstruct in either direction.

I can see that things can go wrong when your are half-way through constructing the new commits. But that's fine: you just leave them as they are, and let git's gc clean them up eventually automatically. As long as you don't touch the user's branches (remember, which are just mutable pointers to immutable commits), the user doesn't need to care that your tool screwed up half-way through.

[sanderjd]

Yeah I'm with you, this can be done, but again, I'm wracking my brain for an example tool that does this without being frustrating sometimes. Even just rebase itself, which is much simpler than what I'm talking about here, has footguns.

But I think this thread has convinced me that someone could almost certainly make better tools for this stuff, and now I'm just wondering why they haven't.