@psantosl I'm fine with a custom branch weight attribute. We use a lot attributes already to filter the branches and stuff. We can also implement our own rules this way, as they are all the same for everybody.
But I think there will be users that have different needs. Then fix branch weights might not be good enough. I thought of 'conditional weights'. Just like conditional colors. Maybe add a multiplyer for branch hierachy level and a reference for the parent branch weight. Then allow it to be a formular like: ([ParentWeight]*10)+1. Make sure that the basic operators (+-*/%) are supported. (I know this is tricky, as the parent branch doesn't have to be in the diagramm, but you still would need to calculate the weight for it. Maybe use promises, to only calculate it when needed?)
This should open the door for any custom layout.
I also like the bounding boxes suggested by @gweronimo.
But in our case this will not work. As I descriped in the user voice linked above: We order the branches in the branch explorer to mirror the release pipeline. So at the top are hotfix-branches, then releases and the release-candidate, then main (Trunk in our case) and then all the issues and features. This is our main repo. But there are other repos, where the bounding boxes would make a lot more sense. You already moved the branch explorer config to the workspace. So the boxing sould be a layout option and then it's fine😃
I think you wouldn't even need an extra boxing algorithm if there was one more reference for the conditional weight formular: IndexOfChildBranch. Then a formular like this would handle the boxing: ([ParentWeight]*100)+[IndexOfChildBranch]. The newest child branch should have the Index 1 and older branches get a heigher index. Then the boxing would be handled by just that
What do you think?