I’m still convinced that our branch origin feature allow you to achieve just what you said, but maybe I mis-undertood your point.
Here’s another representation of what could be achieved
In your previous workflow, you were always based on production, but still pushing to your staging, the side effect being that some changes may already be on your staging environment that you weren’t able to see (In your case, L3 = L1 + all the manual fixes that were done on your development environment).
When you did a push, the result on staging 1 could be unexpected.
You can still achieve the same result (If that’s your prefered way of working) by creating a branch based on production, then switch the origin to staging. (forest branch xxx --origin Production & forest set-origin Staging when you want to push). It is an extra command compared to the previous version of the development work, however you can test what will be pushed on staging locally.
if I push a layout to Staging, it is my layout that matters, not the environment from which it was built on (the famous origin ).
All the layout changes are tracked on an individual branch basis, so switching origin will never “break” anything that was done on the branch.
A concrete example could be the following:
(“Staging” is the origin of “Your feature branch”)
(“Production” is the origin of “Your feature branch”)
set-origin only gives you more control of where your layout changes needs to be propagated + allow you to preview directly what you push or deploy.
I may have missed something in your use case though, so don’t hesitate to correct me if I’m wrong.