> That means when you merge you have no clue which branch was the mainline and which was the fork.
You mean - when looking at the history?
Incidentally, once you get used to jujutsu, you realize that the question is meaningless. A merge is simply the child of two nodes. It's a symmetric operation between the two branches. The thing that makes it "complicated" in git and traditional VCS's is the insistence in assigning a name to the resulting merge (so if you're merging into main, you want to call the new node "main"). Since jujutsu doesn't automatically carry the name forward, you see the "reality" of merge being a symmetric operation (i.e. you don't merge a branch "into" another branch - you are simply merging two branches).
That is exactly my point. I'm not merging two branches together. I'm merging two branches with very clear different meanings together. One of them is our main line, one of them is a feature branch. Everyone talks about all you should develop in main line, and I certainly encourage that. However, often that just isn't practical in a large project for various reasons. Some of them aren't even good reasons, but nonetheless that is the reality.