[sanderjd]

Yes, and the original commenter's point is that git does not support this well, at the data model layer even. Because commits have exactly one parent commit, which is immutable, and because rebasing creates a new commit, rebasing an entire subtree with N nodes under it requires N operations, rather than just 1.

Personally I think it's a pretty small price to pay for the advantage of the single-immutable-parent model, but I do think it's surprising that there aren't better tools for this workflow. I do this all the time, but manually and painstakingly.

[lloeki]

> Because commits have exactly one parent commit

This is not true, merge commits are commits with > 1 parents (octopus merges are merely commits with > 2 parents)

But indeed since the parents commits are part of the computation of a commit's sha then by design changing the parents means changing the commit's sha, which is a very nice property to have.

That said, the model has what we said as a design consequence, but it's perfectly workable to have tooling that walks history and finds branching points and whatnot. Git does it all the time with existing porcelain commands, and I've done it in different contexts (e.g to produce diffs between tip and branching point, analysing which files have changed, and take action pertaining only to these file changes and their dependents) but the gist of it is the same.

It's merely a matter of such porcelain commands not being implemented and not being part of upstream git, so everyone either does it manually or invents their own tooling when they're sick of the pain point.

[sanderjd]

I can't edit anymore, but hopefully people can read my comment with s/commits have exactly one parent/non-merge commits have exactly one parent/ :)

But this did make me realize that the problem with this workflow isn't the "one parent" part at all, it's really just the "immutable parent" part.

But to the main thrust of your comment: Yes, this "porcelain" is what I meant by my surprise that there aren't better tools for this. I think the reason there aren't is that it is really hard to do this well with porcelain, because of requiring a bundle of modifications to the commit tree, where there is no good way to make the whole bundle atomic. So it works fine (and I have a script for it) in the happy path, but it becomes a bit of a nightmare if something doesn't apply quite right.

And that's what I mean by this being unsupported at the data model level, that there is no way to do atomic operations on subtrees as a whole.

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

[zrail]

You're right that the tooling doesn't support it well but commits have more than one parent all the time, they're just called merge commits.

They can actually have as many parent branches as you please but conflicts get harder to deal with the more parents you have.[1]

[1]: https://www.freblogg.com/git-octopus-merge

[sanderjd]

I realized the multiple parents thing was a total red herring. It really is just the immutability.

What I was thinking of was having multiple parents over time rather than at the same time like a merge commit. But that would just be one (not immutable) parent but with a history of what that parent was over time, not "multiple parents".