After reading the comments I found a few ideas that were not represented, so I write them here: 1. Git thinks around a commit, Gitless thinks around a file. Co

After reading the comments I found a few ideas that were not represented, so I write them here: 1. Git thinks around a commit, Gitless thinks around a file. Comparing two tools on a different basis might result in a flawed comparison. The reason that git uses for considering commits over single files is as far as I know, that you as a developer consider consistent states of your project. Before and after a change a project should be able to build, for instance. Often these changes can not happen in a single file and still be consistent. Therefore a project state is considered a unit, not a set of files that are changed on their own. 2. The staging area. Gitless thinks the staging area is a problem so it seems to be removed (might be a wrong interpretation by me). The staging area is quite important though. Sometimes I have made many changes, but I don't want all of them in one commit. In another scenario I did many changes that after squashing plus a few edits here and there might be better represented by a much smaller amount of commits. In both cases I need a space that is not the repository space of completed commits nor the workspace to represent a commit in its creation. The staging area might not be the best way to do it (I don't know a better one, though), but completely removing it without an alternative does not solve the problem.