> 1. The redefinition of “tracked” and “untracked,” and the
elimination of “assume unchanged” and the “staging
area.”
> 2. The redefinition of the concept of “branch,” and the elimination of “stash.”
> 3. The creation of the notion of a “current branch,” and the redefinition of “head.
I would agree that most of the delta from git represents an incremental improvement in usability; staging, stashing, and complex ignore rules are all things that are more likely to get in the way of novice to intermediate git users than help them. That being said, I'd classify those usability issues as minor in the overall picture. Most of them are trivial to smooth out either via git aliases or shell aliases - for example, I've had `ignore`, `show-ignored`, and `unignore` aliases for so long that seeing `git update-index --assume-unchanged foo` on the Gitless site made me realize I'd forgotten that that's what my `ignore` alias is actually doing under the hood.
By far the most complex & difficult aspect of using git (and source control in general) is merge conflict resolution. I'm not convinced Gitless offers much benefit in this aspect and in fact I suspect it may actually make things worse. Complex conflict resolution is when the ability to distinguish between staged and unstaged changes is most useful and sometimes even crucial. Furthermore, while Gitless offering capability to 'pause' a conflict resolution by switching to another branch is neat, I would say it's very rare that I need to ever do so in the middle of a conflict resolution. Difficult resolutions require full concentration - if I find myself needing to switch to another branch in the middle of one, the context switch usually renders me unable to pick up where I left off and I wind up starting over to make sure I'm working from a clean slate.
On the whole, I could see Gitless being valuable in academic environments to facilitate desparately-needed use of source control among researchers/postgrads/scientists. But I would steer clear of it in a software development career as I think it would stunt user's abilities to truly master a core tool of their profession in the long run.
Good points overall, I don’t disagree but I’ll try to give another POV.
I think the focus on stashing is that it’s basically an hidden state. If for instance you switch back to a branch after a while and you don’t remember you stashed, it will just be lost work. Overall I wish stashed were shown as candidate commits, I actually end up making temporary commits that I amend afterward, most of the time.
For the switching between branches during conflict resolution, it might be for people like me who check back and forth reference branches when merging code.
For instance a conflict can be between two feature branches I want to merge, and I’d need to check on master what is the current behavior. Or what’s the behavior on other branches that will need merging as well. Currently I’d just open github/gitlab on the other branches and compare from there, but I’d see the value in switching the local files.
All in all I feel git is too aggressive in making the user deal with all the details when it could have sane non destructive defaults
Yep, I basically agree with all of that. To clarify my main point, I don't think the marginal benefit that Gitless provides for working around these rough edges outweighs the disadvantage of not learning the underlying git functionality and thereby being unable to utilize advanced techniques that are inevitably required in the course of a serious software engineering career.
A quick tl;dr of the referenced paper "Purposes, Concepts, Misfits, and a Redesign of Git" (https://spderosso.github.io/oopsla16.pdf):
> The changes made to Git’s concept model are:
> 1. The redefinition of “tracked” and “untracked,” and the elimination of “assume unchanged” and the “staging area.”
> 2. The redefinition of the concept of “branch,” and the elimination of “stash.”
> 3. The creation of the notion of a “current branch,” and the redefinition of “head.
I would agree that most of the delta from git represents an incremental improvement in usability; staging, stashing, and complex ignore rules are all things that are more likely to get in the way of novice to intermediate git users than help them. That being said, I'd classify those usability issues as minor in the overall picture. Most of them are trivial to smooth out either via git aliases or shell aliases - for example, I've had `ignore`, `show-ignored`, and `unignore` aliases for so long that seeing `git update-index --assume-unchanged foo` on the Gitless site made me realize I'd forgotten that that's what my `ignore` alias is actually doing under the hood.
By far the most complex & difficult aspect of using git (and source control in general) is merge conflict resolution. I'm not convinced Gitless offers much benefit in this aspect and in fact I suspect it may actually make things worse. Complex conflict resolution is when the ability to distinguish between staged and unstaged changes is most useful and sometimes even crucial. Furthermore, while Gitless offering capability to 'pause' a conflict resolution by switching to another branch is neat, I would say it's very rare that I need to ever do so in the middle of a conflict resolution. Difficult resolutions require full concentration - if I find myself needing to switch to another branch in the middle of one, the context switch usually renders me unable to pick up where I left off and I wind up starting over to make sure I'm working from a clean slate.
On the whole, I could see Gitless being valuable in academic environments to facilitate desparately-needed use of source control among researchers/postgrads/scientists. But I would steer clear of it in a software development career as I think it would stunt user's abilities to truly master a core tool of their profession in the long run.