The findings validate the earlier conceptual design analysis in practically all aspects: https://gitless.com/#research
Git doesn't support certain workflows well. For example, how do you split the contents of the staging area into two separate groups? Sapling handles this the same way it handles splitting commits in general. Essentially, it has a greater set of verbs that act on a smaller set of nouns, where Git has a medium set of verbs that act on a medium set of nouns.
> how do you split the contents of the staging area into two separate groups
What is the workflow behind this ask? I don't understand what the goal is. The basic git workflow:
1. Edit and save a tracked file; the changes appear in the working tree.
2. Select some subset of the changes in the working tree to stage them in the index.
3. Form a commit with the changes in the index.
IIUC you want to add a step in between 2 and 3? But the way I see it, 2 is doing what you want. I can split the set of current changes by selectively adding them to the index in preparation for a commit. I can also selectively un-stage changes if I decide I don't want them to become part of the commit.
Between the changes to a file in whatever editor buffer I'm writing in, saving those to disk, moving changes from unstaged to staged, and forming a commit in any of a variety of ways (plain ol' commit, amending a commit, a fixup commit) I can't imagine what other way I need to slice and dice changes. Maybe it's just a failure of my imagination since I've been using Git for so long now and only more basic things like SVN/TFS/CVS before that.
To accomplish your workflow, there doesn't seem to be any need for a staging area at all. You can use an interactive commit selector to stage a subset of changes (or select a set of changes some other way), and then if you want to keep adding/"staging" changes, you can amend the commit you just made.
Occasionally, I do run into the situation where I've staged some changes and then realize that I want to start staging another commit first, but don't want to lose the changed I already staged. Unstaging my current changes means I have to remember and select them again later. I could also just commit what I have staged and start staging a new commit (and perhaps reorder the commits later), but that shows that the staging area was unnecessary in the first place, and I could have used commits to accomplish the same workflow without adding a new set of concepts to my VCS.
The findings validate the earlier conceptual design analysis in practically all aspects: https://gitless.com/#research
Git doesn't support certain workflows well. For example, how do you split the contents of the staging area into two separate groups? Sapling handles this the same way it handles splitting commits in general. Essentially, it has a greater set of verbs that act on a smaller set of nouns, where Git has a medium set of verbs that act on a medium set of nouns.