Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
GeekNights Monday - When your Meat Dies
Tonight on GeekNights, we consider what happens (and should happen) to your bits (i.e., your emails, tweets, hard drive, and collected digital output of a human lifespan), when your meat stops working (i.e., you die). Law, society, human drama, and fear make it a much more complicated issue than you might realize. Do the dead have rights? Should they?
In the news, the Ask.com Toolbar is malware, Ninite is the closest thing to a Windows repo you'll ever find, and Google Authenticator just implements TOTP, which you can totally use for two-factor authentication in anything. Also, Adobe updated their software suite to be subscription only (and this is a good thing).
Download MP3Source Link
Comments
Also, when we accidentally blew off Steve Jackson.
If you're an user interface designer, and you manage to make cosmetic improvements to your original design every so often, THEN YOUR ORIGINAL DESIGN WAS SHIT.
Fuck you
http://www.penny-arcade.com/comic/2011/02/11
http://googlepublicpolicy.blogspot.com/2013/04/plan-your-digital-afterlife-with.html
The thing to keep in mind with how much Git is okay to learn (and how much Git a GUI should expose) is the 80/20 rule. 80% of the time, you're only going to be using 20% of the features, so make those 20% features easy to get to and use, even if that means your GUI wrapper doesn't expose the other 80% of the features. For example, while 'git bisect' can be a very useful command for tracking down bugs (although, admittedly, I only know about it anecdotally as in my small-scale Git usage I have yet to use it myself), someone whose sole job is to produce art for a website or game would probably have no need for it. In that case, it's okay if whatever Git wrapper they're using doesn't include bisect functionality (although, I would agree with the statement that a proper general-purpose Git UI, command-line or GUI, should include bisect -- this is a contrived example for illustrative purposes). Now, if said artist for some reason needed to drop down to the CLI to do something the GUI doesn't do once in a blue moon (AKA the features only used 20% of the time), then it's okay to Google for it or ask the programmer in the cube next door for help.
Git is the same way. You are a professional. Git is one of many tools you use for your job. It is your job to know it inside and out, even though you will only use a small percentage of it on a day to day basis.
Now, we are lucky. Unlike pilots lives are not on the line. It's ok for us to stop and Google how to do something at the moment we have to do it. There is no time limit. The world won't end because you read some documentation and instructions for ten minutes before committing. Even though I'm a Git hipster (using it since before it was cool) I don't know everything. I look stuff up all the time. I know how to bisect, but I do it so rarely I would still look up the man page if I had to do it right now.
What I oppose is the avoidance of learning. I lose huge respect for people with the anti-intellectual attitude of trying to learn as little as possible. It's one thing to get a gui when you understand what it's doing and use the command line when the GUI fails. I use the GitHub Windows GUI client sometimes. It's another thing to use a GUI and other shortcuts to cover everything with abstractions in an attempt to conceal and avoid learning or thinking about what is beneath those abstractions.
The other thing to keep in mind is that a lot of the git features are more "plumbing" (to use the developers' terms for it) than stuff that's typically exposed to the user, AKA "porcelain." Going back to the pilot example, yes, a pilot is expected to know what every switch, button, and gauge in his/her cockpit does. However, a pilot isn't required to know how to change the oil in a jet engine -- that's the mechanic's job. A Git user would probably be fine knowing all the features directly related to source control management without knowing all the intricacies of repository maintenance if you have a complicated setup. I will concede that which features are considered essential for source control management vs. repository maintenance could be a highly contentious issue.
What percentage of Git users could even tell you even the basic structure of how Git does what it does? It's sort of important to know this even to use basic features like add, merge, and rebase that I use pretty much constantly. When Git says "Fast-forward" versus when it says "Merge made by the 'recursive' strategy" you better know what that means or you might find yourself not having the files you expected to end up with.