I created feature-br-1 from main. made some changes, committed, created pull request.
I created feature-br-2 from main. made some changes (some of which conflict with feature-br-1 in very minor ways), committed, created pull request, and merged pull request into main.
per this, I merged main into feature-br-1 , using github, and fixed the the merge conflicts (not complex), and committed.
back in retool app, i switch to feature-br-1. i click “Reset branch”.
After step 4, I was expecting to see changes from main in the current branch (ie feature-br-1), but they were not. 2 data points:
When I click “View changes” for the corresponding retool app, from the branch menu in the bottom toolbar – then click “Past Commits”, I then see a commit with comment “Merge local Retool branch with remote branch” and I do indeed see the changes from main. fwiw, the commit sha for this commit matches the commit sha in github for when main was merged into feature-br-1.
When I click “Review changes” from the top right toolbar under “Commit”, i see all the changes I expected to see, but removed (ie red). So, what is effectively in my current “local” is the removal of the changes that came in with the commit labeled “Merge local Retool branch with remote branch”.
Any idea why this would happen and how I get it cleaned up?
I believe what you’re seeing is due to how Retool separates local editor state from the Git history.
It sounds like the merge from main into your feature branch exists correctly in Git, and Retool can see it in “Past Commits” but Reset Branch does not apply merge commits into the editor. Instead, it just resets the local app to a baseline snapshot. This causes merged changes to appear as removals when comparing local vs remote.
I think the docs make this a bit confusing but in short, but I believe what Retool is doing here is more similar to these git commands:
git fetch origin feature-br-1
git reset
To clean this up, commit the changes shown in “Review changes” so the local Retool state matches the branch’s Git state, or recreate the feature branch from main. Nothing should be lost as it’s a state sync issue rather than a merge failure.
To clean this up, commit the changes shown in “Review changes” so the local Retool state matches the branch’s Git state
What’s shown in “Review changes” is the removal of what was just merged in from main. If I were to commit those, the state in retool won’t match the git state; the retool state will match that of the branch prior to merging in main.
Unfortunately, to move forward, I had to bail on the idea of running multiple feature branches at the same time, which slows down feature development since testing and developing on top of “feature being tested” have to be done sequentially, vs in parallel.
Thanks for letting me know and explaining your situation better. I misunderstood at the start so thanks for the extra details.
In this case, committing what showed up in Review changes would have effectively undone the merge from main, so you made the right call not doing that.
What you’re running into is a limitation of how Retool handles app state with source control, especially with multiple parallel feature branches touching the same app. Unfortunately, it does make that kind of parallel workflow pretty challenging and your note about needing to keep things more sequential is accurate.
Retool’s source control works best with short lived, mostly linear branches. Parallel feature branches on the same app that are merged outside Retool can lead to editor state that cannot be safely reconciled without abandoning one branch.
Outside of that, let me know if you have any other questions or concerns about source control in Retool.