1) The proposition that all systems (and thus git also) should be composed of operations that are orthogonal (no side effects), general (can be used for multiple purposes) and that the system displays a high level of propriety (available operations are limited to those strictly required).
2) Git isn't very good and any of these because it has weird side effects, the operations it does have are often very specific, and there are a whole bunch of different ways of doing similar or related tasks. ...and the author really doesn't like the idea of staging. Which seems irrelevant to the argument, but turns up 4 or 5 times in the paper.
3) Gitless is amazing because it doesn't have the concept of staged changes. See (2) about how the author really likes this:
The elimination of the staging area was enthusiastically received as a
major reduction in complexity, though one student missed being able to
stage files and then only diff those staged files prior to committing
(using git diff --staged). We believe this to be a limitation not so much
in the conceptual model of Gitless but rather in the detailed functionality
of the gl diff command, which appears to be insufficiently versatile.
Well, I believe the author would be more plausible if they didn't have a clear bias towards a result they favoured.
How about looking up, for example, a bunch of things that people use staging for, and then objectively evaluating those, compared to the alternative in a 'no staging' world?
Perhaps you could also include potential limitations of using the orthogonal/general/propriety comparison as the single test for evaluating features? Like, does following that path lead to slower implementations, where the 'concepts' are inherently limiting to the implementation, like with bazaar.
I also found the paper to be very biased. I use the staging area all the time and like it a lot. Also, I really enjoy git's practical approach.
It seems the authors would find hg to be much more enjoyable. It has a stricter approach ("this is how you should do it, because conceptually this is what things should be"), which some people like.
1) The proposition that all systems (and thus git also) should be composed of operations that are orthogonal (no side effects), general (can be used for multiple purposes) and that the system displays a high level of propriety (available operations are limited to those strictly required).
2) Git isn't very good and any of these because it has weird side effects, the operations it does have are often very specific, and there are a whole bunch of different ways of doing similar or related tasks. ...and the author really doesn't like the idea of staging. Which seems irrelevant to the argument, but turns up 4 or 5 times in the paper.
3) Gitless is amazing because it doesn't have the concept of staged changes. See (2) about how the author really likes this:
Well, I believe the author would be more plausible if they didn't have a clear bias towards a result they favoured.How about looking up, for example, a bunch of things that people use staging for, and then objectively evaluating those, compared to the alternative in a 'no staging' world?
Perhaps you could also include potential limitations of using the orthogonal/general/propriety comparison as the single test for evaluating features? Like, does following that path lead to slower implementations, where the 'concepts' are inherently limiting to the implementation, like with bazaar.
Food for thought~