4 ms·

Indeed. I've been using source control of various flavors for 15 years now, and that "Trees" section is completely unparseable by me. Why are there 3 of them?

Indeed. I've been using source control of various flavors for 15 years now, and that "Trees" section is completely unparseable by me. Why are there 3 of them? Why do I care that there are 3 of them? What do I use them for? If I don't use them all directly, why are we talking about them? Further, why are we talking in terms of the actual command-line commands? Surely a version control system as popular as this has tools at least as good as TortoiseSVN so that I don't have to actually type commands into a command prompt like some bearded guy from the '70s. I'd much prefer you tell me the name of the popular Windows/Mac client and walk me through the workflow I'll actually use on a day-to-day basis.

tanoku 15y ago
> I don't have to actually type commands into a command prompt like some bearded guy from the '70s Really? I mean, really?
- jasonkester 15y ago
  Absolutely. I am aware that lots of developers seem to like the command line, but I can't for the life of me understand why. I think visually, so looking at a visual interface such as Windows Explorer is several orders of magnitude more productive than fiddling around with cd/ls to give me a picture of what's going on. Once I find what I'm looking for, I'd much prefer to right click on it and get on with my day than open up a terminal, type out a path, then try to remember some archaic command syntax. As I say, lots of programmers claim to be more productive from the command line than they are in a visual interface. It doesn't make much sense to try to dispute that, but I still find it quite baffling.
  - VMG 15y ago
    Well, as a bearded guy from the 2010's, I prefer the command line to visual interfaces for the same reason I prefer C to LabVIEW.
  - romaniv 15y ago
    I don't think it's a matter of programmers being productive per se. The greatest benefits of command line are the ability to easily store, share and reproduce actions. It's just text. You don't need screenshots to explain something, and everything is scriptable.
  - mquander 15y ago
    Note that source control in particular is particularly amenable to the command line, since the output of source control commands is blobs of text that refers to text files on disk; grepping around in it and wanting to access, process, or modify those files by name is a common operation.
    - adrianmsmith 15y ago
      I'm not sure I agree with that; I mean I use TortoiseSVN and before that TortoiseCVS as my main interface to version control, and have done for the last 10 years. It works perfectly and I don't feel I'm missing the command-line at all. (A goal of Subversion was that its command-line commands produce output which is both easily parsable by humans and machines. But still, I never use it.)
  - vectorpush 15y ago
    >am aware that lots of developers seem to like the command line, but I can't for the life of me understand why. I used to think exactly like this. It takes a while to get used to the CLI workflow, you only start to reap its benefits once you've gained a solid understanding of unix and also developed the autonomy to select the right CLI tools (e.g. tmux, zsh, vim, git) which creates synergy at every tier of your development stack. I have written software on Windows and Linux, and when it comes to most tasks related to software development, GUIs tend to get in the way. GUIs are useful at first because all your options are laid out before you, but the complexity increases since the functionality of the entire system must be abstracted through a visual interface.
  - dustingetz 15y ago
    do you write your programs in sharepoint designer, too? ;)
- nessus42 15y ago
  >I don't have to actually type commands into a command prompt like some bearded guy from the '70s Really? I mean, really? Kids today!
Hemospectrum 15y ago
> Further, why are we talking in terms of the actual command-line commands? (...) I'd much prefer you tell me the name of the popular Windows/Mac client and walk me through the workflow I'll actually use on a day-to-day basis. To be perfectly clear, the command line tools ARE the popular client. The only widely used GUI I'm aware of is the one specific to Github. There are others but they generally expect you to be familiar with the command line workflow. Perhaps this is because Git is easily integrated into IDEs in a way that makes sense for that particular IDE; perhaps it's because the command line interface is actually very good, with features like spelling suggestions (if you've mistyped a command name) and autocompletion scripts (sort of like IntelliSense). By the way, I can't speak for Windows users but the overwhelming majority of Mac and Linux developers are well aware that their shiny GUIs are thin layers over the gross 70s Unix parts underneath. In this world there's no stigma concerning beards or the 70s, and your dismissal of the command line comes across as backwards and absurd. It's a bit like badmouthing non-Hollywood filmmakers because a lot of them work in foreign languages and you "don't want to read some German thing for four hours" when you go to the movies.
spacemanaki 15y ago
To be honest, if you're going to use Git you probably need to at least become familiar with the vocabulary of the command line interface, even if you never use it. This is because so much of the documentation (including unofficial tutorials) and even interfaces of most of the GUI clients are set up to use the same words. This is actually basically a good thing, I think, because it means that switching from one GUI client to another isn't a big deal. Furthermore, it's possible that the real reason so much of the unofficial Git docs just talk about the command line rather than point you at a GUI client (except for documentation for those clients themselves of course) is that the Git GUI clients are still under so much development and in some cases are really lacking basic features (for instance, last I checked, the TortoiseGit client did not support any way of interacting with the index/staging area, which is a pretty important part of Git). I think the parting words of the tutorial "Git from the bottom up" described Git as a library for building a version control system, or something like that, and suggested that we have only just begun to see what people can do with it. I kind of like that idea, that maybe it's possible to bury the complexity of Git underneath a really high level interface, although I don't think that I would actually use it. Git's complicated but it's definitely not rocket science. Plus I generally prefer the command line.

tanoku 15y ago

> I don't have to actually type commands into a command prompt like some bearded guy from the '70s Really? I mean, really?

jasonkester 15y ago
Absolutely. I am aware that lots of developers seem to like the command line, but I can't for the life of me understand why. I think visually, so looking at a visual interface such as Windows Explorer is several orders of magnitude more productive than fiddling around with cd/ls to give me a picture of what's going on. Once I find what I'm looking for, I'd much prefer to right click on it and get on with my day than open up a terminal, type out a path, then try to remember some archaic command syntax. As I say, lots of programmers claim to be more productive from the command line than they are in a visual interface. It doesn't make much sense to try to dispute that, but I still find it quite baffling.
- VMG 15y ago
  Well, as a bearded guy from the 2010's, I prefer the command line to visual interfaces for the same reason I prefer C to LabVIEW.
- romaniv 15y ago
  I don't think it's a matter of programmers being productive per se. The greatest benefits of command line are the ability to easily store, share and reproduce actions. It's just text. You don't need screenshots to explain something, and everything is scriptable.
- mquander 15y ago
  Note that source control in particular is particularly amenable to the command line, since the output of source control commands is blobs of text that refers to text files on disk; grepping around in it and wanting to access, process, or modify those files by name is a common operation.
  - adrianmsmith 15y ago
    I'm not sure I agree with that; I mean I use TortoiseSVN and before that TortoiseCVS as my main interface to version control, and have done for the last 10 years. It works perfectly and I don't feel I'm missing the command-line at all. (A goal of Subversion was that its command-line commands produce output which is both easily parsable by humans and machines. But still, I never use it.)
- vectorpush 15y ago
  >am aware that lots of developers seem to like the command line, but I can't for the life of me understand why. I used to think exactly like this. It takes a while to get used to the CLI workflow, you only start to reap its benefits once you've gained a solid understanding of unix and also developed the autonomy to select the right CLI tools (e.g. tmux, zsh, vim, git) which creates synergy at every tier of your development stack. I have written software on Windows and Linux, and when it comes to most tasks related to software development, GUIs tend to get in the way. GUIs are useful at first because all your options are laid out before you, but the complexity increases since the functionality of the entire system must be abstracted through a visual interface.
- dustingetz 15y ago
  do you write your programs in sharepoint designer, too? ;)
nessus42 15y ago
>I don't have to actually type commands into a command prompt like some bearded guy from the '70s Really? I mean, really? Kids today!

Hemospectrum 15y ago

> Further, why are we talking in terms of the actual command-line commands? (...) I'd much prefer you tell me the name of the popular Windows/Mac client and walk me through the workflow I'll actually use on a day-to-day basis. To be perfectly clear, the command line tools ARE the popular client. The only widely used GUI I'm aware of is the one specific to Github. There are others but they generally expect you to be familiar with the command line workflow. Perhaps this is because Git is easily integrated into IDEs in a way that makes sense for that particular IDE; perhaps it's because the command line interface is actually very good, with features like spelling suggestions (if you've mistyped a command name) and autocompletion scripts (sort of like IntelliSense). By the way, I can't speak for Windows users but the overwhelming majority of Mac and Linux developers are well aware that their shiny GUIs are thin layers over the gross 70s Unix parts underneath. In this world there's no stigma concerning beards or the 70s, and your dismissal of the command line comes across as backwards and absurd. It's a bit like badmouthing non-Hollywood filmmakers because a lot of them work in foreign languages and you "don't want to read some German thing for four hours" when you go to the movies.

spacemanaki 15y ago

To be honest, if you're going to use Git you probably need to at least become familiar with the vocabulary of the command line interface, even if you never use it. This is because so much of the documentation (including unofficial tutorials) and even interfaces of most of the GUI clients are set up to use the same words. This is actually basically a good thing, I think, because it means that switching from one GUI client to another isn't a big deal. Furthermore, it's possible that the real reason so much of the unofficial Git docs just talk about the command line rather than point you at a GUI client (except for documentation for those clients themselves of course) is that the Git GUI clients are still under so much development and in some cases are really lacking basic features (for instance, last I checked, the TortoiseGit client did not support any way of interacting with the index/staging area, which is a pretty important part of Git). I think the parting words of the tutorial "Git from the bottom up" described Git as a library for building a version control system, or something like that, and suggested that we have only just begun to see what people can do with it. I kind of like that idea, that maybe it's possible to bury the complexity of Git underneath a really high level interface, although I don't think that I would actually use it. Git's complicated but it's definitely not rocket science. Plus I generally prefer the command line.