4 ms·

> Resisting GUI's is not a good idea. I disagree. In my personal experience, learning git took a lot of trial and error, but now whatever terminal I sit down

by skohan 6y ago

> Resisting GUI's is not a good idea. I disagree. In my personal experience, learning git took a lot of trial and error, but now whatever terminal I sit down in front of, I know exactly which commands I have to run to do what I want in git. When using a GUI, it's fine for the easy/common stuff, but if I want to do something more complex I have to figure out how to dig through the options provided by the tool to get the result I want.

willis936 6y ago
How is this not a shortcoming of the GUI implementation? What could a CLI do that a GUI could not?
- necheffa 6y ago
  Automation for starters.
- toopok4k3 6y ago
  Nothing has stopped anyone from creating this perfect GUI(or better CLI) for Git that a lot of people seem to be missing. "Show me the code". Or in this case show me the GUI. Maybe the problem is just actually hard and the Git we have is the best current solution.
  - dmitriid 6y ago
    > "Show me the code". Or in this case show me the GUI. Easy: https://gitup.co https://gitup.co It makes things that are hard or cumbersome in the CLI easy and convenient. Things I always do because I'm no longer afraid of mistakes: - split commits at random points - move commits up or down the branch - squash commits up or down the branch - edit commit messages Less often: - cherry pick against current branch - delete branches (local and remote) There are signinficantly more operations hidden there behind convenient shortcuts, but I don't ever (or very rarely) need them because it makes fixing mistakes so easy. And the only reason for advanced git usage I've seen is fixing mistakes.
    - te0006 6y ago
      MacOS only. Otherwise seems to be a dream.
      - dmitriid 6y ago
        Yup. If I ever think about switching from MacOS to a a different OS, GitUp might be the only app that will prevent me from doing that :)
  - Qwertious 6y ago
    Writing a new git GUI doesn't solve the problem, since you need people to adopt it before it's widely installed as default on most OSes by default, and until then you'd probably need to learn the old interface anyway. IIRC there have been various papers on Git's crappy UI and at least one two rewrites (of the interface). Gitless is the name of one. Oh, I forgot the most important thingof all: integration with tooling! QtCreator has support and shortcuts for Git with its commands, but not Gitless.
    - bntyhntr 6y ago
      I contributed inconsequential things to Gitless for a very short amount of time years ago. One of the things that I really liked that I ended up rewriting at home was better highlighting, eg inside-the-line level highlighting like github etc. Also maybe it had native support for vertical split? Either way my at-home added that. No idea if that's still in gitless or if anyone else feels that way, but if I'm gonna live the cli life may as well make diffs comfortable for myself.
  - thotsBgone 6y ago
    magit magit magit
strken 6y ago
I think viewers like gitk or tig, or more powerful tools like magit/sourcetree/etc. when used purely to see your repo's history, are not only acceptable but are the quickest and most intuitive way of understanding what's going on. I'd hate to be restricted to `git show --oneline --abbrev-commit` or similar commands that don't show branches and merges.
- karatinversion 6y ago
  In case you don’t know, there’s also git log --oneline --graph
  - Faaak 6y ago
    tig is way more UI friendly though.
    - petepete 6y ago
      Tig is also my favourite way of staging individual hunks or lines.
user5994461 6y ago
>>> if I want to do something more complex If you want to do something more complex, the reasonable answer is usually to delete the directory and clone again.
- jraph 6y ago
  https://xkcd.com/1597/ https://xkcd.com/1597/
  - ubu7737 6y ago
    This is because every cloned repo stores local state. Local state is sticky, it collects garbage, and it becomes stale very quickly. Doing something complex in git with a local repository is usually not the thing you want. What you want is to fix some garbage state you added to a local. Hence, turning it off and turning it back on, instead of pushing garbage state into the central flow.
- adrianN 6y ago
  I don't think I ever did that.
deleted 6y ago
[deleted]
gpderetta 6y ago
Agree with you. A GUI is fine (and a good thing) as long as it is just for convenience and discoverability, and it doesn't abstract git away, hide its power or try to impose its own workflow. IMHO, a good git GUI would show exactly what commands are being run (so it is useful as a learning tool) and their result and allow it being used along side the cli. I use magit extensively and it has all these properties.
- jidiculous 6y ago
  Yeah I heavily recommend magit to anyone who can tolerate Emacs (which is unfortunately a barrier). It's allowed me to discover so many powerful Git features I would otherwise never have used, and provides a very intuitive interface that does exactly what you expect it to do. This is especially true of its wrappers for rebasing and history editing.
- 9HZZRfNlpR 6y ago
  As well as smartgit, I only use it for squashing and merging stuff but it shows nice output so I guess you can learn the commands from there doing other stuff as well when you're starting to learn git.
mamcx 6y ago
> learning git took a lot of trial and error, but now whatever terminal I sit down in front of This insight why git, like other tools, is stupidely designed. The "wrong" defaults and UX is the DEFAULT, and each USER must learn it. Meaning: UX * N Users = Wasted time and money --- If I present you a screenshoot of a (real!) business apps with mis-aligned buttons, some put in weird places that mean different things that them are supposing by their labels, that use non-standard interactions that mix different UI paradigms, with rare color combinations (aka: vomit palette) , all in a SINGLE window (!), you think the solution is resist a better interface? Why we mock "regular" users or their enterprise providers, but somehow can't with ourselves? I don't know why so many developers live in constant Stockholm syndrome and like it, and resist any suggestion to improve. When anyone ask me about the tools I use (specially asked when somebody look at me using the terminal), if I liked, i say "No, this is the bad and ancient way, but we are here, stuck on this.."
- ubu7737 6y ago
  I think the tool in question (git) is complete and what you want is an incomplete simplification. Preferring incomplete simplifications to complete toolchains is hobbling and a significant hazard to your project.
- edgyquant 6y ago
  How is a GUI a better option than the git cli? Especially for more complex operations.

by skohan 6y ago

willis936 6y ago

How is this not a shortcoming of the GUI implementation? What could a CLI do that a GUI could not?

necheffa 6y ago
Automation for starters.
toopok4k3 6y ago
Nothing has stopped anyone from creating this perfect GUI(or better CLI) for Git that a lot of people seem to be missing. "Show me the code". Or in this case show me the GUI. Maybe the problem is just actually hard and the Git we have is the best current solution.
- dmitriid 6y ago
  > "Show me the code". Or in this case show me the GUI. Easy: https://gitup.co https://gitup.co It makes things that are hard or cumbersome in the CLI easy and convenient. Things I always do because I'm no longer afraid of mistakes: - split commits at random points - move commits up or down the branch - squash commits up or down the branch - edit commit messages Less often: - cherry pick against current branch - delete branches (local and remote) There are signinficantly more operations hidden there behind convenient shortcuts, but I don't ever (or very rarely) need them because it makes fixing mistakes so easy. And the only reason for advanced git usage I've seen is fixing mistakes.
  - te0006 6y ago
    MacOS only. Otherwise seems to be a dream.
    - dmitriid 6y ago
      Yup. If I ever think about switching from MacOS to a a different OS, GitUp might be the only app that will prevent me from doing that :)
- Qwertious 6y ago
  Writing a new git GUI doesn't solve the problem, since you need people to adopt it before it's widely installed as default on most OSes by default, and until then you'd probably need to learn the old interface anyway. IIRC there have been various papers on Git's crappy UI and at least one two rewrites (of the interface). Gitless is the name of one. Oh, I forgot the most important thingof all: integration with tooling! QtCreator has support and shortcuts for Git with its commands, but not Gitless.
  - bntyhntr 6y ago
    I contributed inconsequential things to Gitless for a very short amount of time years ago. One of the things that I really liked that I ended up rewriting at home was better highlighting, eg inside-the-line level highlighting like github etc. Also maybe it had native support for vertical split? Either way my at-home added that. No idea if that's still in gitless or if anyone else feels that way, but if I'm gonna live the cli life may as well make diffs comfortable for myself.
- thotsBgone 6y ago
  magit magit magit

strken 6y ago

I think viewers like gitk or tig, or more powerful tools like magit/sourcetree/etc. when used purely to see your repo's history, are not only acceptable but are the quickest and most intuitive way of understanding what's going on. I'd hate to be restricted to `git show --oneline --abbrev-commit` or similar commands that don't show branches and merges.

karatinversion 6y ago
In case you don’t know, there’s also git log --oneline --graph
- Faaak 6y ago
  tig is way more UI friendly though.
  - petepete 6y ago
    Tig is also my favourite way of staging individual hunks or lines.

user5994461 6y ago

>>> if I want to do something more complex If you want to do something more complex, the reasonable answer is usually to delete the directory and clone again.

jraph 6y ago
https://xkcd.com/1597/ https://xkcd.com/1597/
- ubu7737 6y ago
  This is because every cloned repo stores local state. Local state is sticky, it collects garbage, and it becomes stale very quickly. Doing something complex in git with a local repository is usually not the thing you want. What you want is to fix some garbage state you added to a local. Hence, turning it off and turning it back on, instead of pushing garbage state into the central flow.
adrianN 6y ago
I don't think I ever did that.

deleted 6y ago

[deleted]

gpderetta 6y ago

Agree with you. A GUI is fine (and a good thing) as long as it is just for convenience and discoverability, and it doesn't abstract git away, hide its power or try to impose its own workflow. IMHO, a good git GUI would show exactly what commands are being run (so it is useful as a learning tool) and their result and allow it being used along side the cli. I use magit extensively and it has all these properties.

jidiculous 6y ago
Yeah I heavily recommend magit to anyone who can tolerate Emacs (which is unfortunately a barrier). It's allowed me to discover so many powerful Git features I would otherwise never have used, and provides a very intuitive interface that does exactly what you expect it to do. This is especially true of its wrappers for rebasing and history editing.
9HZZRfNlpR 6y ago
As well as smartgit, I only use it for squashing and merging stuff but it shows nice output so I guess you can learn the commands from there doing other stuff as well when you're starting to learn git.

mamcx 6y ago

> learning git took a lot of trial and error, but now whatever terminal I sit down in front of This insight why git, like other tools, is stupidely designed. The "wrong" defaults and UX is the DEFAULT, and each USER must learn it. Meaning: UX * N Users = Wasted time and money --- If I present you a screenshoot of a (real!) business apps with mis-aligned buttons, some put in weird places that mean different things that them are supposing by their labels, that use non-standard interactions that mix different UI paradigms, with rare color combinations (aka: vomit palette) , all in a SINGLE window (!), you think the solution is resist a better interface? Why we mock "regular" users or their enterprise providers, but somehow can't with ourselves? I don't know why so many developers live in constant Stockholm syndrome and like it, and resist any suggestion to improve. When anyone ask me about the tools I use (specially asked when somebody look at me using the terminal), if I liked, i say "No, this is the bad and ancient way, but we are here, stuck on this.."

ubu7737 6y ago
I think the tool in question (git) is complete and what you want is an incomplete simplification. Preferring incomplete simplifications to complete toolchains is hobbling and a significant hazard to your project.
edgyquant 6y ago
How is a GUI a better option than the git cli? Especially for more complex operations.