The github client is, in my humble opinion, not very good. It's simple but, it's too simple. It's not that intuitive. You still need to know and understand how github works in order to take advantage of the client.
For instance, if you push, and you get some sort of error, the error will be very cryptic for a novice. You'll be googling solutions forever. Why? Because since you don't have a good grasp of working from the command line, you won't know how to implement the solutions that users are saying works.
I think the github client is great, but that may be because I only use GUI clients for the basics: pushing, pulling, branching, committing, and viewing history. I've never used a GUI client for anything more complex than this because, honestly, they all suck at everything else.
What's your purpose in posting that link? Were there interesting comments in that thread that you thought should be mentioned here? If so, would you mind pointing out which?
It doesn't explain WHY. Alright so the file is in the staging area and needs to be committed to a repository, ok. What is the significance of this? Is a staging area a type of repository? What happens if I don't commit? Why have the add and commit stages at all - what value does that provide? Why not just have stuff either committed or NOT? etc.
Unfortunately it is one of those learning exercises written by someone who has forgotten what it was like to learn this stuff, so they presume the reader has tons of "obvious" information (or more importantly a mental model for how a git-like system SHOULD work).
Or maybe it was written with a particular audience in mind (i.e. people moving over from a different version control system).
I like the idea of this, would be good to wean a few people off the github client onto the command line.
I can understand that this wants to create a real repository on my github, but it is asking permission to read/write to private repos, so I stopped at that point.
Why would people need to be "weaned" off of a graphical client towards a command line? Is it a specific client or all of them?
Maybe I'm misunderstanding your sentiment - are you one of those people who thinks that all GUIs are for children and that command lines are for adults or something along that line?
I think it's a case of leaky abstractions: git is sufficiently complicated that no-one (to my knowledge) has abstracted away the original CLI into a GUI that works for everything one would want/need to do with git.
Because graphical clients tend to cause problems when interacting with other people (no shared lingo, using features that aren't implemented in the client, etc), and because Git GUIs in particular tend to be very anaemic compared to the CLI. In particular, I have yet to see a GUI give you access to the reflog so you can undo many kinds of destructive changes, which seems like it would be a useful thing to have for people who don't really understand the system they're using.
Do you have some evidence for your claim that graphical clients tend to cause problems when interacting with other people?
Does one missing feature really make them anaemic?
I understand the git system just fine, I've worked with many other developers who use a disparate set of git tools and I've seen no such problem. I rarely touch the command line and it's just amazing - it's like I have this brain that can understand a system without using the same exact tool that you use to work with it.
Really, I just love the elitist remarks from people who love the command line.
Sure. Few clients (any?) support rebasing or squashed merge commits. So if you work with people who like a simple single-commit-per-feature workflow on the master branch, you're left learning the CLI. Also, "shared lingo": cryptic error messages have been stated elsewhere on this post, and there's no reliable way to tell people how to resolve them (if it's even possible in the GUI they're using).
And stop being an ass by assuming I'm being an ass, please.
TortoiseGit supports them both. Even if none of them did...anemic? Really? I didn't think I was assuming; it was fairly self evident to me, based on the amount of hyperbole being too damn high.
That got me to create an account and an extremely vague idea of what you can do with it. I really didn't understand the syntax of most of what it had me type in. I should probably try it again, but use it for real, and then look for some more real information. It does finish up with a link to gitreal.codeschool.com so that will probably be the next place to go.
Hey hey, if you'd like to drop us a line at help.codeschool.com, we can look into the problem a bit more. I'm in the process of getting ubuntu desktop tossed up to test, but didn't want to keep you waiting.
Congratulations on finding a bug in this tutorial you mean? Typing 'help' when you're stuck is a fairly logical way to get guidance on what you should do next. If this just advances you to the next level, then you haven't gained anything.
What makes you so sure that tybulewicz just wants to cheat?
This is very nice, there are quite a few people at my work that aren't programmers but probably should learn git because it would make their lives easier. Thanks for sharing.
For instance, if you push, and you get some sort of error, the error will be very cryptic for a novice. You'll be googling solutions forever. Why? Because since you don't have a good grasp of working from the command line, you won't know how to implement the solutions that users are saying works.