5 ms·

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 pre

by mooted1 10y ago

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.

gcp 10y ago
I'm not sure that combining stashes and branches wouldn't be handy for advanced users either.
- glandium 10y ago
  I'm not sure I'd know what name to give to my countless stashes.
  - Pxtl 10y ago
    Let the system provide default names for them, based on the name of the branch they came from.
- petre 10y ago
  Why would I commit my breaking, work in progress experiments to a branch? Isn't that what stashes are for?
  - aninhumer 10y ago
    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 10y ago
      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.
  - Pxtl 10y ago
    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 10y ago
    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.
matt4077 10y ago
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."

by mooted1 10y ago

gcp 10y ago

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

glandium 10y ago
I'm not sure I'd know what name to give to my countless stashes.
- Pxtl 10y ago
  Let the system provide default names for them, based on the name of the branch they came from.
petre 10y ago
Why would I commit my breaking, work in progress experiments to a branch? Isn't that what stashes are for?
- aninhumer 10y ago
  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 10y ago
    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.
- Pxtl 10y ago
  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 10y ago
  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.

matt4077 10y ago

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."