[mooted1]

Most of the comments here are missing the point. The functionality and architecture of git aren't what's being criticized, but the way this functionality is presented. In fact, gitless if built on top of git's architecture.

As far as I can tell, gitless still embraces git's distributed and incremental core. It just packages it in a way that's easier to digest. If you're a veteran and know your way around native git flawlessly, gitless probably presents little value. But if you're a notice just learning the tool, gitless can probably accelerate your learning curve without sacrificing functionality—you can still bypass gitless's abstraction layer when you need it.

[matt4077]

Som here are missing the point in the other direction – this isn't about "design" as in "please give me a shiny UI", or "fewer buttons". The paper makes this point quite explicitly:

"These weaknesses have spurred the development of com- mand line wrappers and GUIs whose primary goal is to re- move some of Git’s complexity (most notably, EasyGit [1] and GitHub’s desktop client). These make largely cosmetic changes, through more attractive user interfaces, more con- sistent terminology in commands and documentation, and a focus on more commonly used commands. But their suc- cess seems to have been fairly limited, and most people still use the command line interface distributed with Git as their primary frontend, or fall back to it for accomplishing more complex tasks.

We believe that the usability problems of Git run deeper, and can only be addressed by a more fundamental reworking that reconsiders the underlying concepts. This is not to say that such a reworking cannot be achieved in a lightweight fashion. Indeed, our own reworking hides Git behind a ve- neer just as these other tools do. The difference however, is that we are willing to completely reconsider the core con- cepts that are presented to the user."

[gcp]

I'm not sure that combining stashes and branches wouldn't be handy for advanced users either.

[glandium]

I'm not sure I'd know what name to give to my countless stashes.

[Pxtl]

Let the system provide default names for them, based on the name of the branch they came from.

[petre]

Why would I commit my breaking, work in progress experiments to a branch? Isn't that what stashes are for?

[Pxtl]

New branch flagged as a "stash", named related to the branch it came from. So branch myFeature has stash myFeature-stash-1 stash branch. Hide stash branches from branch lists unless specifically requested.

Do the same with stash commits. Store them as regular commits flagged as broken and hide them when viewing history.

Hell, do the same for most history-modifying operations. The ability to flag intermediate commits as "unimportant" would let you be able to keep a clean history without rewriting it.

[RichardCA]

Maybe you want to push your work to a remote server as a way to back it up.

Maybe you want to share your work with others even though it's still in a rough state.

Maybe you have automated tests in your CI process and you want to try those tests on your side-branch.

The point is you might want to wrap workflow around your stuff, even if it's experimental and broken.

Git doesn't make these choices for you. You get to make them.

[aninhumer]

Because sometimes stashes are longer lived than we expect, and they're hard to work with if you need to do anything more complicated than popping. (Like resolving conflicts.)

I find that making a work-in-progress commit, and then resetting later ends up saving a lot of hassle overall. Having support for this beyond aliases (including putting that commit in a new branch) would be nice.

[petre]

Okay, points taken. But git enables me to commit expermiments to a branch anyway if I decide to. Gitless' lack of stash would force me to commit experiments to a branch.