Live data from Hacker News

Got 15 minutes and want to learn Git?

try.github.com

61–70 of 178 posts

Re: Got 15 minutes and want to learn Git?

#61
This doesn't help you learn Git. It helps you learn the commands for Git if you're already familiar with version control.

I can kind of sort of use Git already but frankly I don't understand what half of the commands do nor do I understand the point of them.

Technically the only commands I would assume you need are:

- Get repository - Merge repository (with comment) - Get history/comments

But Git has dozens of different things it can do that expand on the above and learning it all is time consuming and there is no one single place to do so (and no the documentation isn't a good place because it isn't a intuitive way to learn).

The biggest hurdle of using Git is that Git has its own vocabulary for things; and there is nothing "common sense" about that vocabulary. Even people who attempt to explain it assume you know another version control so use vocabulary from that.

Re: Got 15 minutes and want to learn Git?

#62
post #56
post #30

NOTE: This is not a rant, I'm just trying to give you a peek into my mind as I tried out this tutorial. I'm doing my best to describe my confusion. I have no clue how to use Git, and I've been trying to wrap my head around it for a while. Unfortunately, this is yet another tutorial that is very frustrating even though it's designed to target noobs like myself. So, I added octocat.txt to my staging area. Success! ...…

I sympathize. What is really necessary are not tutorials on how to use Git--it isn't that hard, after all, for most of us--but more of a description of actual workflow. Not HOW you issue Git commands; but how to use Git. It would be interesting to read articles about how a single programmer uses Git, how a small programming team, how a distributed team uses Git. Similar articles about how a team producing art, or tex…

Agreed. And not only for Git. For basically anything else in programming land you get to have either hands on quick guides or spec listing. There's serious shortage of good, moderately abstract, short overviews of what something actually does and how it does it.

Take Vim for instance. When I first got to it, I found only resources that are paraphrased with "this command does that. that command does that... nth command does that". Now, if only someone described buffers, tabs and windows to me (like in an article that was recently linked to here on HN), or told me that commands can be described as acronyms of verbs and nouns etc. I'd be much more proficient with Vim now.

For Node.js, I found some talks/presentations from its creator that really hit this spot.

I still haven't found anything like that for Git.

Re: Got 15 minutes and want to learn Git?

#64
post #30

NOTE: This is not a rant, I'm just trying to give you a peek into my mind as I tried out this tutorial. I'm doing my best to describe my confusion. I have no clue how to use Git, and I've been trying to wrap my head around it for a while. Unfortunately, this is yet another tutorial that is very frustrating even though it's designed to target noobs like myself. So, I added octocat.txt to my staging area. Success! ...…

I figured out Git, and I'm not that clever, so don't worry! The staging area (aka the index) is where you put things before they become a commit. You don't always want to commit all of your changes at once. The index is there so you can commit the changes you want instead of just committing all the changes every time. `git commit` means "turn the contents of the index into a commit". A commit is a set of changes that…

Unfortunately you fell right into the trap he said everyone trying to explain Git does. The first paragraph is complete nonsense unless you already understand it.

You first call it a staging area and then you clarify with an "index," but you never clarify what an index is?! The second paragraph doesn't improve the situation much.

Ultimately I think there is a language breakdown here. People who explain Git seem to be unable to do so without using Git-language, and it is very difficult to understand the Git-language without understanding how it is used.

So therefore it is a chicken/egg problem. You somehow need to know the language to understand Git, but to understand the Git you need to understand the language.

PS - I know you're trying to help; it is just one of those things where I am not even sure it can be explained in that way.

Re: Got 15 minutes and want to learn Git?

#66

Does this straight up just not work for anyone? I am typing in commands and am getting no feedback. Just getting a new $ line.

I'm having the same problem. Other people are complaining about this in their support forums.

Doesn't speak too highly of Code School in general.

Re: Got 15 minutes and want to learn Git?

#68
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…

for those who aren't familiar with the nitty gritty, what's happening here is that bash (your shell) expands the "glob" (* .txt) before it ever runs ls, so what actually gets run isn't 'ls * .txt', it's 'ls foo.txt bar.txt dog.txt' etc.

but when you put quotes around "* .txt", that tells bash not to expand the glob.

so in the above case, '* .txt' is actually getting passed into git, rather than 'foo.txt bar.txt dog.txt' etc. I'm not a git user, but it sounds like git has special handling for "* .txt" which causes it to perform its own glob expansion, which happens to also include descending into directories. hilarity ensues.

EDIT: I can't seem to figure out how to type * .txt without triggering the italicized formatter, so I had to put a space after the asterisk. urgh.

Re: Got 15 minutes and want to learn Git?

#69

Earlier quoted context omitted.

I figured out Git, and I'm not that clever, so don't worry! The staging area (aka the index) is where you put things before they become a commit. You don't always want to commit all of your changes at once. The index is there so you can commit the changes you want instead of just committing all the changes every time. `git commit` means "turn the contents of the index into a commit". A commit is a set of changes that…

Unfortunately you fell right into the trap he said everyone trying to explain Git does. The first paragraph is complete nonsense unless you already understand it. You first call it a staging area and then you clarify with an "index," but you never clarify what an index is?! The second paragraph doesn't improve the situation much. Ultimately I think there is a language breakdown here. People who explain Git seem to be…

I'm not saying it's an "index" to clarify what "staging area" means, I'm saying "index" is a synonym for "staging area" so if he runs into the word "index" somewhere, he knows it's just a different word for the same concept. For Christ's sake, there's nothing magic about the words, they're just names for something. If you didn't know what a dog was, and I said "a dog (aka a canine) is a domesticated animal related to a wolf", I'm not expecting the word "canine" to add anything to the explanation, I'm just throwing it in there in case you run into someone else who says "canine" instead of "dog", just so you know that in both cases they're referring to the same type of thing.

In any case, a staging area only makes sense in the context of trying to create a commit, and I think I did usefully define what a commit is. Maybe that part should have come first.

Re: Got 15 minutes and want to learn Git?

#70
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…

It had you use `git add '* .txt'` because there were untracked txt files in the octofamily directory. `git add * .txt` would have just added the txt files in the root of the directory and ignored the octofamily directory.

I wouldn't think this is so much an error as they _want_ you to use '*.txt' to add the files in the subdirectory along with the files in the root. They could have touched better on the difference between quotes and no quotes though.

Post reply on HN