4 ms·

The only thing that jumps out at me is the visual of the git tree diagram on the left - other than that why not just use the command line? Am I missing somethi

by kzisme 10y ago

The only thing that jumps out at me is the visual of the git tree diagram on the left - other than that why not just use the command line? Am I missing something?

Lxr 10y ago
Not sure why this is downvoted, I'm also interested to know how popular these sort of tools are compared to command line git and what the main advantages are.
- kzisme 10y ago
  I'm curious as well...I've tried using the Git integration within MSVS ,and it was a ~very~ unpleasant experience. I suppose in some instances it may be nice to visually see changes, but I've always preferred the command line for git.
blakeyrat 10y ago
Because I have dyslexia and command lines are torture for me. Do you really need to justify people making tools more usable? Seriously? Isn't it enough to say, "if there's a quality UI, way more people can comfortably use the tool."
DanPristupov 10y ago
When you use a git GUI some console actions can be made easier: - I can stage/unstage/reset my changes line-by-line - I can observe the whole repository structure as it was at the moment of commit - Gui client automatically keeps my submodules in the valid state so I don't need to check their state after each checkout - I can quickly review the whole repo history (sometimes it can be useful when I am involved in a new project) - I can see clearly the commits which are going to be pushed
- belovedeagle 10y ago
  All of these things are readily available from the native interface. Hmmm... Maybe a GUI man page browser could replace hundreds of these projects...
macandcheese 10y ago
Because when you're doing anything outside of git commit am- "whatever" it's nice to be able to see the complete implications of your actions, what files have been modified, what lines in those files have changed, etc.,
- rnicholson 10y ago
  git commit -v gives you the diffs provided you don't also use -m. Personally, I find -m to be a dangerous flag for commit for exactly the reasons you described not mention its hard to really do detailed multi-line commit messages with -m.
Myrmornis 10y ago
Having `git status` in a window-based UI is very nice. In magit, the window is divided into two sections horizontally: unstaged changes and staged changes. Each section contains multiple changed files that can be folded or expanded, and individual lines or hunks can be staged/unstaged as needed in order to prepare a commit. While it is an emacs extension, non-emacs users can start it with a one-line command and treat it as a standalone application, e.g. https://github.com/dandavison/emacs-config/blob/master/bin/emacs-magit https://github.com/dandavison/emacs-config/blob/master/bin/e... I know at least one non-emacs user who uses it that way. There are some videos on youtube showing the magit UI. It would of course look more modern were it not an emacs extension but, emacs lisp programmers being as they are, I believe it is the most fully featured and powerful graphical git UI in existence.

by kzisme 10y ago

The only thing that jumps out at me is the visual of the git tree diagram on the left - other than that why not just use the command line? Am I missing something?

Lxr 10y ago

Not sure why this is downvoted, I'm also interested to know how popular these sort of tools are compared to command line git and what the main advantages are.

kzisme 10y ago
I'm curious as well...I've tried using the Git integration within MSVS ,and it was a ~very~ unpleasant experience. I suppose in some instances it may be nice to visually see changes, but I've always preferred the command line for git.

blakeyrat 10y ago

Because I have dyslexia and command lines are torture for me. Do you really need to justify people making tools more usable? Seriously? Isn't it enough to say, "if there's a quality UI, way more people can comfortably use the tool."

DanPristupov 10y ago

When you use a git GUI some console actions can be made easier: - I can stage/unstage/reset my changes line-by-line - I can observe the whole repository structure as it was at the moment of commit - Gui client automatically keeps my submodules in the valid state so I don't need to check their state after each checkout - I can quickly review the whole repo history (sometimes it can be useful when I am involved in a new project) - I can see clearly the commits which are going to be pushed

belovedeagle 10y ago
All of these things are readily available from the native interface. Hmmm... Maybe a GUI man page browser could replace hundreds of these projects...

macandcheese 10y ago

Because when you're doing anything outside of git commit am- "whatever" it's nice to be able to see the complete implications of your actions, what files have been modified, what lines in those files have changed, etc.,

rnicholson 10y ago
git commit -v gives you the diffs provided you don't also use -m. Personally, I find -m to be a dangerous flag for commit for exactly the reasons you described not mention its hard to really do detailed multi-line commit messages with -m.

Myrmornis 10y ago

Having `git status` in a window-based UI is very nice. In magit, the window is divided into two sections horizontally: unstaged changes and staged changes. Each section contains multiple changed files that can be folded or expanded, and individual lines or hunks can be staged/unstaged as needed in order to prepare a commit. While it is an emacs extension, non-emacs users can start it with a one-line command and treat it as a standalone application, e.g. https://github.com/dandavison/emacs-config/blob/master/bin/emacs-magit https://github.com/dandavison/emacs-config/blob/master/bin/e... I know at least one non-emacs user who uses it that way. There are some videos on youtube showing the magit UI. It would of course look more modern were it not an emacs extension but, emacs lisp programmers being as they are, I believe it is the most fully featured and powerful graphical git UI in existence.