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

How to teach Git

rachelcarmena.github.io

Post reply on HN
Print view View original

91–100 of 273 posts

Re: How to teach Git

#91

Post by someguy101010 »

Mirioron wrote: post #67
Sir_Cmpwn wrote: post #38

I disagree with this idea. The best way to learn git is to read the git book, in this order: chapters 1, 10, 2, 3, and the rest at your discretion. This way teaches you about the internals first, and if you understand the internals the rest of git is pretty intuitive. https://git-scm.com/book/en/v2

Great idea. This kind of culture is why there are a lot of people that don't and probably never will use git.

The article is about how to get a more fundamental understanding idea on how git works, and this book demonstrates fundamental ideas on how git works. I don't see a problem in this reccomendation. If you want just a cursory knowledge of how to use git to get by, this probably not the right choice, but that's not really what this discussion is about is it?

Re: How to teach Git

#92

Post by pjmlp »

Sir_Cmpwn wrote: post #66
collyw wrote: post #64

Earlier quoted context omitted.

That's a lot of reading for a tool that should be making life easier.

It's an engineering tool. You'll be using it all day every day for the rest of your career, the investment is worth it.

I will save this answer for when anyone complaints about C++ or Rust being complex languages.

Re: How to teach Git

#93

Post by nemetroid »

url00 wrote: post #69
aurumpotest wrote: post #36

Earlier quoted context omitted.

I use it quite a lot, especially with `git add -p` to stage only parts of a file for an atomic commit.

This has never made sense to me. I've seen others say that they commit only parts of a file. How does this scenario start? Are you working on solving one problem, but then notice some other unrelated issue and fix that too, before committing the first change?

One common scenario is that I'm working on one problem, and in the process of solving that issue do some refactoring of related code. In this case, I want to commit the refactoring (which does not change the program's behaviour) before committing the changes that do change the program's behaviour.

Re: How to teach Git

#94

Post by Sir_Cmpwn »

pjmlp wrote: post #92
Sir_Cmpwn wrote: post #66

Earlier quoted context omitted.

It's an engineering tool. You'll be using it all day every day for the rest of your career, the investment is worth it.

I will save this answer for when anyone complaints about C++ or Rust being complex languages.

How about now :) Rust and C++ are complicated languages, and that's bad.

But git isn't complicated. Git is a handful of simple ideas composed in interesting ways. It looks complicated because there's a lot of porcelain commands with a lot of options, but all of them are just manipulating the same simple internals which, once understood, are clear and intuitive.

Re: How to teach Git

#95

Post by war1025 »

cyborgx7 wrote: post #19

Here is my personal recommendation for getting more comfortable with git. Use "git status" a lot. Everytime you do something in git, and before you do something, do a "git status" and see what you change with your commands. And what you didn't change. Also "git log".

`git log -p` is my favorite obscure git command. Shows you commit by commit changes. If you specify a path, it limits to only those files. If you do a single file you can do `git log -p --follow ` and it will track the file across moves and renames.

Also `git whatchanged` is a super helpful command to see just the list of files that changed in each commit

Re: How to teach Git

#96

Post by pjc50 »

oblio wrote: post #80
Ajedi32 wrote: post #47

Earlier quoted context omitted.

`git log` on its own (with no flags) isn't that useful, as it's missing a lot of important information. I prefer `git config --global alias.lg "log --color --graph --oneline --decorate"`. Then you can just type `git lg` and get a much more useful overview of the state of your current branch.

Git in many occasions (including when using git log) feels like the designer just threw their hands up and said: "F*ck this shit, make your own UI on top if you want to use this tool!" I don't think Torvalds has a proper excuse for the pain and suffering he's inflicted on millions of developers worldwide :( (To the people going: "Oh, it's Open Source!". Sure, so are Mercurial, Fossil, etc.)

I don't think it was ever really intended for worldwide use by Linus, it was intended to exactly replicate his workflow and his alone. The real responsible party is github; I'm not sure how they came to dominate?

Re: How to teach Git

#97

Post by rkangel »

oblio wrote: post #80
Ajedi32 wrote: post #47

Earlier quoted context omitted.

`git log` on its own (with no flags) isn't that useful, as it's missing a lot of important information. I prefer `git config --global alias.lg "log --color --graph --oneline --decorate"`. Then you can just type `git lg` and get a much more useful overview of the state of your current branch.

Git in many occasions (including when using git log) feels like the designer just threw their hands up and said: "F*ck this shit, make your own UI on top if you want to use this tool!" I don't think Torvalds has a proper excuse for the pain and suffering he's inflicted on millions of developers worldwide :( (To the people going: "Oh, it's Open Source!". Sure, so are Mercurial, Fossil, etc.)

This makes a lot more sense when you realise that Linus thought he was building a low level tool that people would build a UI on top of. The 'original' git command line was more a proof of concept and engineering tool than something aimed at actual use.

Re: How to teach Git

#98

Post by pjc50 »

dahart wrote: post #68
JediWing wrote: post #21

Earlier quoted context omitted.

So I have a solid mental of git, and I understand the theoretical need for the staging area. However, I find the occasions for using the staging area in practice are few and far between, for the simple reason that I can't test and execute the code that's in the staging area without also having the code from the working directory also be there. It feels like after having partially staged some of my working directory,…

You never amend commits or rebase locally before pushing? I rebase before pushing almost every time. Git’s workflow wouldn’t even be sane without the staging area. This is what allows you to fix mistakes and make your work presentable for remotes.

> Git’s workflow wouldn’t even be sane without the staging area. This is what allows you to fix mistakes and make your work presentable for remotes.

I did exactly the same diff/tidy/diff workflow when I used p4 and svn, neither of which make a distinction between "working directory" and "staging area".

Re: How to teach Git

#99

Post by rkangel »

Mirioron wrote: post #67
Sir_Cmpwn wrote: post #38

I disagree with this idea. The best way to learn git is to read the git book, in this order: chapters 1, 10, 2, 3, and the rest at your discretion. This way teaches you about the internals first, and if you understand the internals the rest of git is pretty intuitive. https://git-scm.com/book/en/v2

Great idea. This kind of culture is why there are a lot of people that don't and probably never will use git.

Unfortunately, it isn't possible to effectively use git without knowing something about the internals. You can do the basics taught more 'by rote', but sooner or later you're going to run into something unexpected, or something complex you need to do and you need to understand the data model in order to have a chance of sorting it out.

Re: How to teach Git

#100

Post by doubleunplussed »

pjc50 wrote: post #11
radarsat1 wrote: post #4

Earlier quoted context omitted.

> WHY there is a staging area I understand your second point, but I have a hard time understanding the difficulty with this part. Why is it hard for people to understand the idea of staging? You put things in a box one at a time before closing the box. Does it require more explanation than that? What do people find difficult about it?

People are very used to the web "save always" style: There is one document, and you're editing it. Most people will be familiar with the traditional desktop "save" model where you have to do something to make your changes permanent. People often then learn that there is a local file and some remote file: they can cope with a save -> upload workflow. Lots of traditional VCS turn this into a save -> commit workflow. Gi…

There are a whole bunch of layers now, though they're all useful.

1. Is my document saved?

2. Are the changes staged?

3. Are the changed committed?

4. Are the changes pushed to my fork on e.g. github?

5. Are the changes merged into the upstream repository on e.g. github?

Post reply on HN