15 ms·

Its opposite for me. I am very comfortable with the command line. It lets me do crazy things and if I mess up, quitely crawl back to the peaceful place. GUI in

Its opposite for me. I am very comfortable with the command line. It lets me do crazy things and if I mess up, quitely crawl back to the peaceful place. GUI integrations have some advantages but the knowledge is not transferrable. Different GUIs work differently but the commands stay the same. I think both can complement each other. I use Pycharm a lot and it is a lot easier to see diffs or file history there. I think the same can be done with cmd as well but I don’t think I ever bothered to learn advanced commands.

meuk 8y ago
I like the commandline as well, but most of my coworkers are happy using a git GUI, and I can see why: 1. Most GUI's give you an overview of the changes before committing. 2. Most GUI's let you commit and push in one go, and also show unstaged changes so you don't forget to add/commit/push anything. 3. A good git GUI is explorative. Newbies just remember the icons to click at first, and they learn more by exploring menus and reading messages. 4. Commit histories are easier to view and filter. 5. Exotic steps are easier to do, since you don't have to remember commands you barely use. 6. Adding remotes is a piece of cake.
crispyambulance 8y ago
> and if I mess up, quitely crawl back to the peaceful place. Ok, but getting to THAT level of comfort takes a long time and many failed attempts. While I understand why folks may want a GUI for git, I am continually amazed that there hasn't been an effort to "refactor" git commands so they're more consistent, easier to remember and easier to discover. It's a miracle that git has taken root so strongly, given it's shitty user experience. I've been using git for years, and STILL, I need my cheatsheets and google far more than I would ever admit in person. Anything that's outside of heavily practiced workflow-- and I'm in a world of confusion.
quietbritishjim 8y ago
Committing to version control is one of the ideal uses of a GUI. You can skim your eye over the files you've changed, and flick between their diffs by just clicking on their file names, before going ahead with the commit. You can simultaneously cast your eye over recent commits in the revision history. Of course these are easily accesible with git status and git log (|less) but it's not the same as dealing with the information graphically. I would posit the ed text editor for comparison. Why bother with a graphical text editor (including terminal editors like Vi and Emacs)? After all, you can look at the context surrounding lines you wish to edit by entering the appropriate ed commands. I think it comes down to developers being so used to working with command line tools that they don't give GUIs a proper chance - ironically the exact objection they have with less experienced users not using the command line.

meuk 8y ago

I like the commandline as well, but most of my coworkers are happy using a git GUI, and I can see why: 1. Most GUI's give you an overview of the changes before committing. 2. Most GUI's let you commit and push in one go, and also show unstaged changes so you don't forget to add/commit/push anything. 3. A good git GUI is explorative. Newbies just remember the icons to click at first, and they learn more by exploring menus and reading messages. 4. Commit histories are easier to view and filter. 5. Exotic steps are easier to do, since you don't have to remember commands you barely use. 6. Adding remotes is a piece of cake.

crispyambulance 8y ago

> and if I mess up, quitely crawl back to the peaceful place. Ok, but getting to THAT level of comfort takes a long time and many failed attempts. While I understand why folks may want a GUI for git, I am continually amazed that there hasn't been an effort to "refactor" git commands so they're more consistent, easier to remember and easier to discover. It's a miracle that git has taken root so strongly, given it's shitty user experience. I've been using git for years, and STILL, I need my cheatsheets and google far more than I would ever admit in person. Anything that's outside of heavily practiced workflow-- and I'm in a world of confusion.

quietbritishjim 8y ago

Committing to version control is one of the ideal uses of a GUI. You can skim your eye over the files you've changed, and flick between their diffs by just clicking on their file names, before going ahead with the commit. You can simultaneously cast your eye over recent commits in the revision history. Of course these are easily accesible with git status and git log (|less) but it's not the same as dealing with the information graphically. I would posit the ed text editor for comparison. Why bother with a graphical text editor (including terminal editors like Vi and Emacs)? After all, you can look at the context surrounding lines you wish to edit by entering the appropriate ed commands. I think it comes down to developers being so used to working with command line tools that they don't give GUIs a proper chance - ironically the exact objection they have with less experienced users not using the command line.