I personally don't feel comfortable with mercurial, but that may be because I don't understand it. It's been a long time since I last touched it, but I remember thinking that the way it does branches was just needlessly complicated and cumbersome. Why does closing a branch even need to be a thing?
> you don't need the index for this, you need to track conflict state
This is what the index does. You don't need the index in mercurial, because you have something that is like the index, but not called the index.
Maybe the UI is better because "add" is called resolve, but that is really just an alias away.
> and then ... what?
Then you push it to remote somewhere and a CI system runs tests for you. Maybe you can do something productive in the meantime.
If you're just testing locally, then there's little difference, but I would still prefer testing a committed state, knowing it's safe in the repository and I can't clobber it afterwards.
I can't disagree more. The index is entirely unnecessary, as umpty thousands of happy Mercurial users can testify.
> Being able to use the VCS tool to fashion a commit separately from what is in the worktree allows you to
... record states which never existed, and haven't been tested. It's an antipattern. If you are doing this a lot, you are doing development wrong. In the rare occasions where you do want to do it, Gitless and Mercurial, like every other source control tool, give you a way to fine-tune the set of files which go into the commit. They don't need an index to do it.
> Furthermore, when resolving conflicts, the index is extremely useful because you can work through a conflict (which often can span multiple files) piece-by-piece and easily tell whether you've already fixed everything, run diffs on what's resolved and what isn't, etc.
Again, you don't need the index for this, you need to track conflict state. As Mercurial does:
https://www.mercurial-scm.org/wiki/TutorialConflict
> I've seen some people argue that they don't want to commit something that has not been tested, but I don't understand this argument. Why would you test something that isn't committed?
This is a very interesting perspective! It doesn't immediately sound immensely practical, though. Say i want to test a fraction of the current working tree's state; i commit, and then ... what? Create a fresh clone of that state somewhere so that i can run tests on it?