An aside but this is giving me ClearCase config_spec vibes.
Memory is hazy - possibly due to trauma - but you could create a config_spec which would make your view (roughly: working tree) pick up different bits of the filesystem from different branches. Branches might only exist on some of the filesystem, depending on how you set up auto branching and what you checked out, and you had to know what the config_spec rules everyone was working to were or the whole repository was effectively broken.
It was very complicated to get your head around - I guess not helped by the codebase I was working on at the time which tended to concentrate change in the same 20 files.
I feel like this is much different. We're not saying "patch these things together into a materialized view", we're saying "here is the diff between your working directory and origin/master, which branch owns which hunk" and keeping that mapping around.
We keep monitoring it until we see changes upstream (someone merged into master) and then we let you update the difference (merging or rebasing commits you made if needed)
Spec was a huge pain. For our project it contained around 50 directories to fetch from. Directory per component with own versioning. Only a few persons know working combinations you could use.
Memory is hazy - possibly due to trauma - but you could create a config_spec which would make your view (roughly: working tree) pick up different bits of the filesystem from different branches. Branches might only exist on some of the filesystem, depending on how you set up auto branching and what you checked out, and you had to know what the config_spec rules everyone was working to were or the whole repository was effectively broken.
It was very complicated to get your head around - I guess not helped by the codebase I was working on at the time which tended to concentrate change in the same 20 files.