Issue with rebasing children interactively

[Rami Cohen]

Consider these scenarios:

1. Repository with a main branch.
2. Dev branch created off main, with 4 additional commits.
3. Try to rebase children interactively on the latest main commit.
4. ---> This works fine, no issues.
5. Now create another local branch from main branch but don't add any commits to it or switch to it. Simply have another local branch whose last commit is the same as main.
6. Try to rebase children interactively on the latest main commit.
7. ---> Nothing happens.
8. Delete the dummy commit you created in step #5.
9. Try to rebase children interactively on the latest main commit.
10. ---> This works fine, no issues.

It looks like the rebase children interactively function requires that the commit of the starting point has at most one local branch. No issue if there are additional remote branches on this commit.

Since the rebase is done from a commit, not from a branch, it is not clear why having a second branch prevents the operation.

Is this a bug?

[Tom Vanassche]

I'm experiencing a similar problem with the latest version (3.4.24). This wasn't an issue with the previous version.

My steps to reproduce:

1. Create a branch of the master
2. Add a few commits
3. Use interactive rebase and try changing the message of any of the new commit
5. Press OK, and the rebase will get stuck

Tried waiting for an hour, but no progress at all. The interactive rebase is basically stuck on "Rebasing (1/xxx)".

It doesn't matter if there is only 1 commit since branching off, or multiple commits. Simply trying to change the commit message of any new commit makes the rebase hang.

The only thing that works is making a new branch and cherry picking the commits and making the needed changes along the way. But this takes more time.

So the interactive rebase is basically just broken/useless in the last version.

[lbca lbca]

I also encountered the same problem as you, version 3.4. 24. This version was fine before

[GEVOL Control]

Thanks for describing the issue in such detail — I ran into the same problem with version 3.4.24 and was equally puzzled until I realized that simply having another local branch at the same commit could break interactive rebase.

What’s really concerning here is how regressions like this make it into a production release. Especially today, when AI-assisted tools can generate comprehensive test coverage with relatively low effort, it's surprising that something as fundamental as interactive rebase would fail in such a specific — yet realistic — scenario.

I've been using SourceTree for quite some time, but unfortunately, quality issues like this have been recurring. It’s frustrating when core Git features, which work flawlessly in the command line, become unpredictable or unusable in the GUI. This particular regression doesn’t inspire confidence in relying on SourceTree for serious workflows going forward.

Hopefully, this gets addressed soon — but it would be great to see more robust testing and stability in future releases. For now, I'm sticking to the command line or considering other tools for Git GUI support.