I haven't read any books or longer tutorials on Git. I find it easy to use and if I run into trouble I just Google after help (which happens a few times a week). Throughout the day I mostly use 9 Git commands. Here are the top 9 commands I use:
git checkout X
git checkout -b new-branch
git commit
git add; git mv; git rm;
git pull --rebase
git rebase origin/master
git push origin X
I have used this for a long time without running into huge amounts of trouble (and if I need to revert back to a specific or do anything special I can always consult Google). The bottom line is: For simple cases Git is really simple to use and to learn. You don't need to become a Git master to use Git.
The problem is that people introduce the powerful features of Git that only a few percentage of people will ever use.
Everything you just said is exactly why Git is not simple and can not be learned in 15 minutes. Just by operating from the command line you've already left the realm of "simple" in my opinion. Having to learn 9 commands is not simple. Having to hit Google for help multiple times per week is not simple.
I strongly, strongly disagree with your assertion that "for simple cases Git is really simple to use and to learn". I've watched many programmers, artists, and designers who have used source control struggle with Git from day 1. I'm sorry, it's just not simple and if it were this topic wouldn't come up over and over and over.
Again, I say none of this as a slight to Git. Complicated things are complicated. That's ok, but pretending they aren't isn't helpful.
The problem (for me, anyway) isn't that git basically requires a command line to do anything - the problem is that git's command line syntax is exceptionally complex. I'm used to being able to do `man foo' and get a short listing of all possible orderings of parameters and arguments that a tool will accept. git's syntax is so powerful that it isn't possible to do this - a lot of the summaries in the manpages have the dreaded one-line `command [ARGS] ... [PARAMETERS] ...' that I tend to associate with a lot of the GNU tools.
Maybe if someone added an EBNF grammar to the documentation...
I am a productive programmer and I am absolute uncomfortable with the command line. I can't count the times I have written
svn commit -m "Finally fixed bug #123!"
...only to get some weird bizarro error because I should have used '' or escaped the !. This is usually when I am deeply focused on some programming language or bug #123.
Tower.app is the only reason I've ever touched git, and the line-by-line staging and committing is nothing I would ever bother to do with a CLI.
Well, suit yourself. It's just a tremendously useful skill to have. Makes it a bit less of a hassle to ssh into the odd server to check the logs, or dump a database, or use tools that don't have a GUI.
I mean, fundamentally, you're typing things to a computer and then the computer does what you typed. Why should that notion be uncomfortable to a programmer of all people?
Oh, I can use the terminal, I can also theoretically write PHP, and every vim user can theoretically use Eclipse. But that doesn't mean that any of us would be comfortable with it - we'd all be anxious and focused on the tool (instead of the problem at hand) not to break stuff left and right.
What kind of argument is that? How can you ever learn anything new with this attitude? If you never leave your comfort zone you will never make any progress. Just do it.
I have listed things that I have tried out for months. I happen to really hate these particular three. Now I study other things that I find more worthy of human lifetime, some of them just as useful to a programmer.
Why can you not accept that someone could possibly hate working with a shell or git's CLI even after trying them out? I don't get it.
I think this is a general problem with people with extreme addiction to IDEs and Windows based UIs.
I've known people in my team who can't do any work on the command line comfortably. I see this problem especially among people who work on Frontend and especially Java developers.
If a certain set of tools are making you dumber by the day, know it for sure that it will be automated or you will be replaced by lesser skilled cheap labor inevitably.
> If a certain set of tools are making you dumber by the day
How does "not comfortable with the command line" translate to "dumber by the day?" If people get their training using IDEs and go on to be productive using primarily IDEs, how does being uncomfortable with the command line reflect on their intelligence in any way?
> know it for sure that it will be automated or you will be replaced by lesser skilled cheap labor inevitably.
Yes, the mundane, confusing use of the git command line is here to stay and the dumb "actually design and engineer an application" world of IDEs is going to be replaced by robots. You are a fucking genius. Only on the internet can such backwards and completely worthless logic be said because if you tried to say this shit to anyone in real life you'd be laughed out of the room.
How does "not comfortable with the command line" translate to "dumber by the day?" If people get their training using IDEs and go on to be productive using primarily IDEs, how does being uncomfortable with the command line reflect on their intelligence in any way?
I agree with you completely. Being familiar with the idiosyncrasies of the console does not make you smarter than people who aren't; you've just learnt different things.
You are a fucking genius. Only on the internet can such backwards and completely worthless logic be said because if you tried to say this shit to anyone in real life you'd be laughed out of the room.
You went off the rails here. You can disagree without being abusive. Downvoted, sorry.
>>How does "not comfortable with the command line" translate to "dumber by the day?" If people get their training using IDEs and go on to be productive using primarily IDEs, how does being uncomfortable with the command line reflect on their intelligence in any way?
Because the common characteristics of such people is to heavily depend on intellisense and auto complete to do almost any task. Tool generated code is so common in those communities most code is generally taken care by the IDE. Import statements, exception handling, try/catch blocks, loop generation in context of previous statements. The list endless...
When you are tuned to thinking this way you basically lose any touch on proactive coding. You stop thinking, the IDE starts thinking for you. You stop reading API because you know everything is about to be auto completed, anyway. Now the issue is you are offloading the job of thinking to the IDE. This is dangerous.
If a rookie can do what an expert can, just by using an IDE. I guess its time for the expert to fear for his job.
Lack of knowledge of command line utils is just one such case. You can either learn how to use awk/sed/Perl + Text processing utils. Or you can open up eclipse and endlessly re implement what the command line has to already offer.
When you start looking this from the larger perspective, refusing to learn tools designed to solve a problem in the proper way and taking short cuts, actually makes your life difficult on the longer run.
>>Yes, the mundane, confusing use of the git command line is here to stay and the dumb "actually design and engineer an application" world of IDEs is going to be replaced by robots. You are a fucking genius. Only on the internet can such backwards and completely worthless logic be said because if you tried to say this shit to anyone in real life you'd be laughed out of the room.
Definition of dumb varies. Definition of 'usability' varies. By your definition a programming language could be called dumb, a microprocessor and its interfaces can be called dumb, A pilots cabin and controls can be called dumb(As they are both not easy to laymen, and have never even made progress in that direction). A tool like git is not designed to be a toy or recreation software. Its supposed to manage text/binary versions in situations faced by individuals, small and large teams managing software projects.
Therefore it is designed to cover features in that direction, for programmers. Not for your ordinary user who needs to use the ATM to withdraw money.
Complaining about command line's usability being difficult is same as complaining about an Airplane's cockpit.
>>Because the common characteristics of such people is to heavily depend on intellisense and auto complete to do almost any task. Tool generated code is so common in those communities most code is generally taken care by the IDE. Import statements, exception handling, try/catch blocks, loop generation in context of previous statements. The list endless...
Because that code can be easily automated... choosing not to is just wasting your time.
>>When you are tuned to thinking this way you basically lose any touch on proactive coding. You stop thinking, the IDE starts thinking for you. You stop reading API because you know everything is about to be auto completed, anyway. Now the issue is you are offloading the job of thinking to the IDE. This is dangerous.
False. You stop thinking about boilerplate code and API details and free yourself to focus on the actual problem at hand.
>>If a rookie can do what an expert can, just by using an IDE. I guess its time for the expert to fear for his job.
Do you consider writing good code an issue of speed typing? I have no idea why you believe an IDE would be able to make a beginner into an expert.
>>Lack of knowledge of command line utils is just one such case. You can either learn how to use awk/sed/Perl + Text processing utils. Or you can open up eclipse and endlessly re implement what the command line has to already offer.
Or you could use your IDE to write something that the command line doesn't do. Nice strawman.
I can never understand why people who are in the business of automating tasks (programmers) hate tools that automate tasks (IDE's), of all things.
Ruby on Rails. It's not even that high-level, but:
1. The number of import statements in the typical code file in the typical Rails app is anywhere between 0 and 3, heavily weighted towards 0. Turns out you can metaprogram class-loading behavior in high-level languages and it just seems to work.
2. It's rare to find good places where exception handling is the best way to go in Rails, except for debugging purposes, in which case the default Rails behavior--to render the exception in a 500 if you're running in developer mode--is usually what I want.
3. Aren't try/catch blocks exception handling?
4. `.each do |e|`; `.map do |e|`. I can handle those on my own.
OK, there's serious shit you can't write in Ruby, but languages like Scala and Clojure are equally high-level, probably even more high-level, and yet have better performance and JVM integration.
Still, I understand there are legitimate reasons you'd use a language like Java, and given a language like Java, I can understand that you'd want an IDE to automate the drudgery. But I still don't like IDE's, because they're an ugly solution to a problem that doesn't need to exist. If I can concisely express what I want to do in my code to Eclipse, I should fundamentally be able to express the same idea just as concisely in the code itself.
I'm mostly ignorant of Ruby, so maybe you can help me out.
1. And how exactly do they get away with that? What if you wanted to use a class that had a name conflict with a Ruby library class? Import/require are useful for namespace resolution. It seems that not having them would just be limiting your ability to name things cleanly.
2. Well sure, exception handling shouldn't be the rule, but how often you use them isn't usually a language concern (except maybe with Java and checked exceptions). Nonetheless, when you do use them, having your IDE give you shortcuts to write the boilerplate code is a plus.
> What if you wanted to use a class that had a name conflict with a Ruby library class?
I just try to avoid going around calling my classes things like "Fixnum" or "Array".
Seriously though, this kind of thing is all set up at the framework level, though you do sometimes have explicit requires for external libraries (gems) that you bring in. The Ruby standard library isn't that big, and Rails' libraries are named and namespaced intelligently and pretty much sit in the background without having to be explicitly invoked too much.
It helps that the main source of Ruby libraries is RubyGems, most RubyGems have a class or namespace named after the name of the gem, and there's a canonical source of RubyGems that doesn't allow you to use the name of gems that already exist.
> Well sure, exception handling shouldn't be the rule, but how often you use them isn't usually a language concern (except maybe with Java and checked exceptions). Nonetheless, when you do use them, having your IDE give you shortcuts to write the boilerplate code is a plus.
I guess Ruby exception handling just doesn't have much boilerplate code.
> Complaining about command line's usability being difficult is same as complaining about an Airplane's cockpit.
The cockpit is an interface (a GUI even) tailored for flying. The command line is an interface tailored mainly for administration and automation with a focus on text and files. A broom is tailored for cleaning the office and I use it when I have to. But what does this all have to do with what a programmer generally should be able to do?
I know the stereotype of the dumb Java/Eclipse programmer that apparently upsets you, and they certainly don't embrace the command line. But please, that does not imply that hating the command line turns one into a worse programmer.
> You are taking it personally.
(Not me, but:) You jump from not being comfortable with the command to getting dumber by the day, then eventually being obsolete. It's not really hard to read some elitism into that. Same for:
> A tool like git is not designed to be a toy or recreation software.
> Therefore it is designed to cover features in that direction, for programmers. Not for your ordinary user ...
"Everything you just said is exactly why Git is not simple and can not be learned in 15 minutes. " haha agreed
"Just by operating from the command line you've already left the realm of "simple" in my opinion." It's all about the audience, people who are used to CLIs will find new CLIs that are similar to the ones they already know simple.
"I strongly, strongly disagree with your assertion that "for simple cases Git is really simple to use and to learn"
I've taught git to designers in 15 minutes and had them off and running for the next ~6 months. That said even after a few months of using it I still lack understanding of some of the core concepts.
Even the simplest form of source control involves checkout->change/add->commit->checkin. And this is regardless of any version control system you will ever use.
The only extra stuff there is branching and merging. And to be frank. I've never felt the individual need to do that. Its a different story if you have a big team and members working on several projects which merge at a time. Now that's difficult with any VCS, not just git.
But for individual development anybody should be able to do the checkout->add/change->commit>checkin easily.
Reading through the comments here is infuriating, and it's no wonder people don't git what the big deal is.</lame>
With git you can share you current work to any arbitrary remote branch. The implications are your half baked feature can get pushed up and your coworker can do a checkout on the new remote branch. If they have suggestions they can make a change which you can cherry-pick off their branch into your branch. Also, you can branch off your current working branch, rebase master and merge their new branch in and push that up to master when everything works as expected. Try that workflow without breaking the central repo effecting everyone else's work in SVN.
The problem is that people introduce the powerful features of Git that only a few percentage of people will ever use.