6 ms·

Save time with a GUI? Seriously??? Keyboard strokes are, by any definition, much faster than mouse pointing-and-clicking. I have yet to find a single GUI that

by yuvadam 14y ago

Save time with a GUI? Seriously??? Keyboard strokes are, by any definition, much faster than mouse pointing-and-clicking. I have yet to find a single GUI that gets stuff done faster than what I can achieve with a command line prompt.

mitchty 14y ago
Yes, I use magit to stage chunks in emacs. Even if I have modified a file and end up staging the whole thing, looking at what i'm staging is way more useful than the way stock git presents things.
mnutt 14y ago
I can't imagine myself using a GUI for git, but there are some things that are faster with a GUI and mouse than with a keyboard. Almost all of them involve some kind of visual feedback. For instance, lately I've been working on some projects that involve absolutely positioning HTML elements on the page. This is a huge pain using a text editor--you make an estimate, save it, reload the page, see how it looks, and repeat. Just clicking and dragging is much, much easier. Other than that, I generally think that keyboard is a faster input, though an 80-character terminal window is often a poor choice for visual feedback. Termkit has some interesting ideas: http://acko.net/blog/on-termkit/ http://acko.net/blog/on-termkit/
- bowmessage 14y ago
  For the future, mnutt: I love Chrome's developer tools, you can directly edit CSS rules from the browser by right clicking on it and selecting inspect element. Helps a lot with these situations!
  - recursive 14y ago
    And it's a gui!
- Evbn 14y ago
  TermKit author got mad at the community last year and went underground. :-( No idea if it will ever launch.
daveungerer 14y ago
How about staging 8 files out of 10 that are currently modified, with no matching glob patterns for the CLI to use? I don't care how fast your keyboarding is, simply selecting the 8 (even better, select all and unselect the 2 you don't want) and dragging them into the index is the fastest way. Or how about firstly determining which old commit you would like to revert a single file to, then secondly doing the actual revert. I can just view the file's log at a glance, get the revision I want, right-click and select "Reset File to This Commit". By the way, I love Vim. But your disdain for "pointing-and-clicking" sounds like so much machismo.
- motti 14y ago
  git add -i
  - tesmar2 14y ago
    Great tip, didn't know that!
- goldfeld 14y ago
  Some people literally actually don't have a mouse. It gets that good.
  - to3m 14y ago
    These people can use the keyboard - git has comprehensive command line support, even if it isn't always as quick as git gui.
- Evbn 14y ago
  They day I learned that gvim has support for mouse hover tooltips, was a great day.
jules 14y ago
Your working speed is limited by typing or clicking? Mine is limited not by the speed I output information, but by the speed I get input. GUIs excel at that. A graphical view of source history is much better than what you get from the CLI, which is like living life while looking through a straw.

by yuvadam 14y ago

mitchty 14y ago

Yes, I use magit to stage chunks in emacs. Even if I have modified a file and end up staging the whole thing, looking at what i'm staging is way more useful than the way stock git presents things.

mnutt 14y ago

I can't imagine myself using a GUI for git, but there are some things that are faster with a GUI and mouse than with a keyboard. Almost all of them involve some kind of visual feedback. For instance, lately I've been working on some projects that involve absolutely positioning HTML elements on the page. This is a huge pain using a text editor--you make an estimate, save it, reload the page, see how it looks, and repeat. Just clicking and dragging is much, much easier. Other than that, I generally think that keyboard is a faster input, though an 80-character terminal window is often a poor choice for visual feedback. Termkit has some interesting ideas: http://acko.net/blog/on-termkit/ http://acko.net/blog/on-termkit/

bowmessage 14y ago
For the future, mnutt: I love Chrome's developer tools, you can directly edit CSS rules from the browser by right clicking on it and selecting inspect element. Helps a lot with these situations!
- recursive 14y ago
  And it's a gui!
Evbn 14y ago
TermKit author got mad at the community last year and went underground. :-( No idea if it will ever launch.

daveungerer 14y ago

How about staging 8 files out of 10 that are currently modified, with no matching glob patterns for the CLI to use? I don't care how fast your keyboarding is, simply selecting the 8 (even better, select all and unselect the 2 you don't want) and dragging them into the index is the fastest way. Or how about firstly determining which old commit you would like to revert a single file to, then secondly doing the actual revert. I can just view the file's log at a glance, get the revision I want, right-click and select "Reset File to This Commit". By the way, I love Vim. But your disdain for "pointing-and-clicking" sounds like so much machismo.

motti 14y ago
git add -i
- tesmar2 14y ago
  Great tip, didn't know that!
goldfeld 14y ago
Some people literally actually don't have a mouse. It gets that good.
- to3m 14y ago
  These people can use the keyboard - git has comprehensive command line support, even if it isn't always as quick as git gui.
Evbn 14y ago
They day I learned that gvim has support for mouse hover tooltips, was a great day.

jules 14y ago

Your working speed is limited by typing or clicking? Mine is limited not by the speed I output information, but by the speed I get input. GUIs excel at that. A graphical view of source history is much better than what you get from the CLI, which is like living life while looking through a straw.