Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Got 15 minutes and want to learn Git?

try.github.com

Post reply on HN
Print view View original

161–170 of 178 posts

Re: Got 15 minutes and want to learn Git?

#161

Post by CrLf »

philwelch wrote: post #114
CrLf wrote: post #103

Earlier quoted context omitted.

That doesn't explain the fundamental part. Why is there a staging area in the first place? Place yourself in the shoes of a subversion user, the workflow is very simple and intuitive given that: 1. the repository is a (remote) place where my project is stored 2. the local copy is where I modify my project Then, a commit is just pushing your modifications to the repository where other people can go get them. Now, with…

> Why is there a staging area in the first place? Because you don't always want to commit every change you've made or every new file you've added. > If a commit doesn't push my changes to a remote repository, why do I care? If I have my code in a working state, I'd like to save that "version" somewhere, so I can make a whole bunch of changes without worrying about whether or not I can get back to a working state. Thi…

The point isn't about me reading tutorials to learn Git.

The point is about convincing people to use Git by pointing them to tutorials and have them come back with blank stares and "why do I need this exactly?" questions.

Re: Got 15 minutes and want to learn Git?

#162

Post by grannyg00se »

A lot of these Git tutorials seem to walk you through a series of commands as if knowing the commands is knowing Git.

I think they should focus on scenarios instead. Short stories like: "Bob's code is working well but he wants to try something that might be completely misguided. He knows better than to mess with his working code....." Then at the end of the story a command is introduced. Also, some kind of indication of what Git is actually doing when you issue that command. When you tell Git to branch, what actually happens to the file system? When you say git status, what is it actually looking at?

And please, don't start a tutorial on Git without introducing the three area paradigm (working, staging/index, commit)

Here's a talk by Scott Chacon of GitHub. http://www.youtube.com/watch?v=ZDR433b0HJY

It's over an hour long and very detailed.

Re: Got 15 minutes and want to learn Git?

#164

Post by Peaker »

forrestthewoods wrote: post #81

Can we please stop pretending that Git is simple and easy to learn? If that were true then there wouldn't be "Learn how to use Git in minutes!" posts every other day. The fact of the matter is that Git is incredibly powerful but also complex and hard to learn. This isn't a bash on Git at all. It's ok! Sometimes complicated things are just that, complicated. I believe we'll have better guides and tutorials if people s…

Git is a very simple and powerful system covered by a hideous and complicated CLI. The simplicity is simply hidden.

Re: Got 15 minutes and want to learn Git?

#165

Post by gurkendoktor »

hkolek wrote: post #158
gurkendoktor wrote: post #148

Earlier quoted context omitted.

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.

Re: Got 15 minutes and want to learn Git?

#166

Post by thyrsus »

p2e wrote: post #55

As someone new to git, I was dissapointed to see that: git add "*.txt" added all of the .txt files from the current directory AND all of the .txt files contained within a subdirectory. I would have expected the same files to get added as those that would have shown up using: ls *.txt For other new users: I've been told that this is an error in the tutorial. The tutorial forced the use of quotes but apparently they ar…

I tried varying my commit messages from those recommended, (e.g., in the second commit, I typed 'git commit -m "Commit all the things!"'), and the commit messages weren't reflected in the "git log" output. It's not clear to me now how much of this is canned response and how much actually runs git.

Re: Got 15 minutes and want to learn Git?

#167

Post by kmkemp »

kamaal wrote: post #149
crono5788 wrote: post #136

Earlier quoted context omitted.

> 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 l…

You are taking it personally. >>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 t…

>>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.

Re: Got 15 minutes and want to learn Git?

#168

Post by florestan »

I seem to have great problems with this tutorial. And not that it actually does not help me with why and how I should use it in different scenarios (wich it doesn't), but my entire computer crashed for the first time. Got a major error, lots of blinking on the screen and the had to reboot several times. When I tried open it again, chrome crashed every single time. Not impressed.

Re: Got 15 minutes and want to learn Git?

#169

Post by prodigal_erik »

spacemanaki wrote: post #121
prodigal_erik wrote: post #118

Earlier quoted context omitted.

What disturbs me about that workflow is that your commits have literally never been tested because the staging area contents aren't accessible as a working copy. I for one am adamant about not littering my history with all my crap that didn't run, so I much prefer to commit the mixed work and then rewrite history to tease out and regress the independent changes. I pretty much always test and commit my workspace as-is…

> It'd be easier if I could stash some but not all of my changes to get them out of my workspace temporarily, but this hasn't bugged me enough to figure out how to implement that. Here, let me help you, from the examples section of `git help stash`: "Testing partial commits You can use git stash save --keep-index when you want to make two or more commits out of the changes in the work tree, and you want to test each…

Thanks for the very genteel RTFM. I think you've pointed that out before, I just mischaracterized the process as quarantining the changes I don't want yet rather than rescuing the changes I do and forgot the mechanics.

Re: Got 15 minutes and want to learn Git?

#170

Post by nohbody »

philwelch wrote: post #115
forrestthewoods wrote: post #108

Earlier quoted context omitted.

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".…

> Just by operating from the command line you've already left the realm of "simple" in my opinion. Git is a tool for programmers. There's no excuse for a programmer to be uncomfortable with the command line.

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...

Post reply on HN