7 ms·

Personally, I think using git from the commandline is too complicated for the purpose it serves in most companies. Using a git GUI works quite well for people

by meuk 8y ago

Personally, I think using git from the commandline is too complicated for the purpose it serves in most companies. Using a git GUI works quite well for people inexperienced with git.

abhishekjha 8y ago
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.
pjmlp 8y ago
Even for experienced people, I rather spend my time on GUI tools and only drop into the CLI on as needed basis. From UI/UX point of view, developers are users as well, but many seem to think developers should put up with bad interfaces.
- jamesb93 8y ago
  I'm in the same boat. When I do something bad CLI helps me fix it, but otherwise an interface is really useful for me.
chrismorgan 8y ago
The problem is that most Git GUIs are just that—Git GUIs, with much of their functionality being a thin layer over a subset of the decidedly poor-usability Git command line interface. There are small areas of their functionality where I find that some do a really good job, but mostly they still require you to learn the underlying concepts and nuances of Git rather than of version control in general. I am not aware of any that have evidently been constructed from the other end, focusing on the users and workflows, bending Git into shape around that. Naturally, there are dangers of being opinionated like that when it comes to playing ball with other users that might not use that particular client; this is a hard problem, which explains the paucity of attempts. (Making “a Git client” is easy; making a good tool for users is hard. It’s similar in other domains where there’s an easy path and a far better path—the far better path is seldom trodden.)
spurgu 8y ago
This is like teaching people to drive a car with an automatic gearbox.
- pjmlp 8y ago
  Which happens to be the only option on future car driving technologies.
  - spurgu 8y ago
    Not sure whether your statement is ignorant or insightful. Yes, once electric cars (with superior traction and brake control) take over automatic gearboxes (actually electrics don't even have gearboxes) will be the norm, but as long as there are engines driven on dinosaur fuel there will be a need for manual gearboxes. Which is why you should learn how to drive one. Once you're able to do that, driving an automatic is trivial, which was the point I was trying to illustrate.
    - dahart 8y ago
      > Not sure whether your statement is ignorant or insightful I’ll answer that for you. It’s insightful. In the U.S. today, less than 2% of new cars sold are manual now. Automatic gearboxes are well beyond the norm already. https://www.chicagotribune.com/classified/automotive/sc-auto-cover-manual-transmissions-20180710-story.html https://www.chicagotribune.com/classified/automotive/sc-auto... I didn’t understand why you said there will always need to be manuals for vehicles that run on gas... what do you mean?
      - dave7 8y ago
        > In the U.S. today, less than 2% of new cars sold are manual now. Automatic gearboxes are well beyond the norm already. At that percentage, the U.S. is a huge outlier however, and accounts for quite some chunk of of worldwide automatic gearbox equipped vehicle production on it's own. The automatic gearbox remains the less popular option worldwide [1], though as you can see they are more popular than they were before. [1] https://www.statista.com/statistics/204123/transmission-type-market-share-in-automobile-production-worldwide/ https://www.statista.com/statistics/204123/transmission-type...
tasubotadas 8y ago
Same here. I am using Git for over 10 years now (with breaks), but I always pain me getting into the CLI (apart from basic add/commit/push/pull). Almost all commands require flags to give you a decent behaviour and the documentation is seriously lacking. For example, I've never had any problems with Mercurial. Everything just works there and it is intuitive. You can never lose data there, and it has extremely sensible defaults.
dahart 8y ago
> Using a git GUI works quite well for people inexperienced with git. I agree, and I wish there was a really good git GUI that either abstracted git nicely, or was as powerful as the CLI, or both. I’ve tried many of them, in production, and there aren’t any that give you a UI for everything git can do. The problem I’ve noticed is that people raised on the GUI often don’t understand how to get out of trouble once they have a serious problem. Also the GUI tends to be a crutch that prevents them from learning the CLI well. Git is natively a CLI and it really shows once you know both. Git’s CLI interface is awkward and hard to learn, and all the GUIs for git are somewhat awkward, both due to git being awkward, and also because trying to fit UI workflow onto CLI commands introduces awkwardness. All git GUIs are incomplete interfaces to git, there are none that give you access to all of git... specifically things like finding lost data and managing repos is something you’ll need to drop to the CLI for.

by meuk 8y ago

Personally, I think using git from the commandline is too complicated for the purpose it serves in most companies. Using a git GUI works quite well for people inexperienced with git.

abhishekjha 8y ago

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.

pjmlp 8y ago

Even for experienced people, I rather spend my time on GUI tools and only drop into the CLI on as needed basis. From UI/UX point of view, developers are users as well, but many seem to think developers should put up with bad interfaces.

jamesb93 8y ago
I'm in the same boat. When I do something bad CLI helps me fix it, but otherwise an interface is really useful for me.

chrismorgan 8y ago

The problem is that most Git GUIs are just that—Git GUIs, with much of their functionality being a thin layer over a subset of the decidedly poor-usability Git command line interface. There are small areas of their functionality where I find that some do a really good job, but mostly they still require you to learn the underlying concepts and nuances of Git rather than of version control in general. I am not aware of any that have evidently been constructed from the other end, focusing on the users and workflows, bending Git into shape around that. Naturally, there are dangers of being opinionated like that when it comes to playing ball with other users that might not use that particular client; this is a hard problem, which explains the paucity of attempts. (Making “a Git client” is easy; making a good tool for users is hard. It’s similar in other domains where there’s an easy path and a far better path—the far better path is seldom trodden.)

spurgu 8y ago

This is like teaching people to drive a car with an automatic gearbox.

pjmlp 8y ago
Which happens to be the only option on future car driving technologies.
- spurgu 8y ago
  Not sure whether your statement is ignorant or insightful. Yes, once electric cars (with superior traction and brake control) take over automatic gearboxes (actually electrics don't even have gearboxes) will be the norm, but as long as there are engines driven on dinosaur fuel there will be a need for manual gearboxes. Which is why you should learn how to drive one. Once you're able to do that, driving an automatic is trivial, which was the point I was trying to illustrate.
  - dahart 8y ago
    > Not sure whether your statement is ignorant or insightful I’ll answer that for you. It’s insightful. In the U.S. today, less than 2% of new cars sold are manual now. Automatic gearboxes are well beyond the norm already. https://www.chicagotribune.com/classified/automotive/sc-auto-cover-manual-transmissions-20180710-story.html https://www.chicagotribune.com/classified/automotive/sc-auto... I didn’t understand why you said there will always need to be manuals for vehicles that run on gas... what do you mean?
    - dave7 8y ago
      > In the U.S. today, less than 2% of new cars sold are manual now. Automatic gearboxes are well beyond the norm already. At that percentage, the U.S. is a huge outlier however, and accounts for quite some chunk of of worldwide automatic gearbox equipped vehicle production on it's own. The automatic gearbox remains the less popular option worldwide [1], though as you can see they are more popular than they were before. [1] https://www.statista.com/statistics/204123/transmission-type-market-share-in-automobile-production-worldwide/ https://www.statista.com/statistics/204123/transmission-type...

tasubotadas 8y ago

Same here. I am using Git for over 10 years now (with breaks), but I always pain me getting into the CLI (apart from basic add/commit/push/pull). Almost all commands require flags to give you a decent behaviour and the documentation is seriously lacking. For example, I've never had any problems with Mercurial. Everything just works there and it is intuitive. You can never lose data there, and it has extremely sensible defaults.

dahart 8y ago

> Using a git GUI works quite well for people inexperienced with git. I agree, and I wish there was a really good git GUI that either abstracted git nicely, or was as powerful as the CLI, or both. I’ve tried many of them, in production, and there aren’t any that give you a UI for everything git can do. The problem I’ve noticed is that people raised on the GUI often don’t understand how to get out of trouble once they have a serious problem. Also the GUI tends to be a crutch that prevents them from learning the CLI well. Git is natively a CLI and it really shows once you know both. Git’s CLI interface is awkward and hard to learn, and all the GUIs for git are somewhat awkward, both due to git being awkward, and also because trying to fit UI workflow onto CLI commands introduces awkwardness. All git GUIs are incomplete interfaces to git, there are none that give you access to all of git... specifically things like finding lost data and managing repos is something you’ll need to drop to the CLI for.