No I don't mean commits. The UX is different and it would be really cumbersome to try to split work in progress code.
What would be the suggested solution? Make two empty commits and the cherry pick change chunks into each? Then to shelve/stash a change you need to make a new branch and cherry pick back? Sounds really cumbersome compared to the current staging workflow.
Making many wip commits with small chunks and then squashing and/or splitting them into proper sharable commits once I'm done is my usual mode of operation whenever a single staging area is not enough for what I'm working on. `git rebase -i` makes it a breeze. I'm trying to imagine what multiple named staging areas would bring into the picture there that isn't already provided by commits and I struggle.
If you think that's easier or just as easy as adding an id to the staging commands then I guess its meaningless to you. I think it can be made much easier than what's possible now and I think there's value in fleshing out the part of git that this is actually about, ie staging incomplete commits.
If its actually single commit, auto-squashed branches behind the scenes, that's fine.
What would be the suggested solution? Make two empty commits and the cherry pick change chunks into each? Then to shelve/stash a change you need to make a new branch and cherry pick back? Sounds really cumbersome compared to the current staging workflow.