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

51–60 of 273 posts

Re: How to teach Git

#51

Post by avar »

pletnes wrote: post #44
avar wrote: post #43

I contribute to git, if anyone's got any UI warts they're bothered by in particular I'd love to hear about them. Maybe it's something we can fix.

LFS works by installing hooks. This prevents me from adding my own. Also the one-hook-only policy makes it harder to share hooks.

Yeah this would be great. I started working on adding support for .d/* in addition to a couple of years ago, that got to a proof-of-concept stage, but some of the long tail is hard to handle so I dropped it, but it could be finished.

There was also a disagreement about what the semantics should be, e.g pre-receive.d/* hooks failing on the first one that failed in glob() order or not, which has implications for whether they can run in parallel.

The bit that stuck from those patches was being able to configure the the core.hooksPath variable to a hook path, which sometimes can with some stretching fulfill some of the use-cases, but most users end up with a meta-hook runner of some sort.

Re: How to teach Git

#52

Post by navinsylvester »

No one is appreciating the effort and a different take here. Let me congratulate the author on job well done.

There are people who love illustrated explanation and for those these are perfect. This is just meant as a template which others can use to build the illustrated material and in no way a comprehensive git tutorial.

Re: How to teach Git

#53

Post by pletnes »

avar wrote: post #51
pletnes wrote: post #44

Earlier quoted context omitted.

LFS works by installing hooks. This prevents me from adding my own. Also the one-hook-only policy makes it harder to share hooks.

Yeah this would be great. I started working on adding support for .d/* in addition to a couple of years ago, that got to a proof-of-concept stage, but some of the long tail is hard to handle so I dropped it, but it could be finished. There was also a disagreement about what the semantics should be, e.g pre-receive.d/* hooks failing on the first one that failed in glob() order or not, which has implications for whethe…

Glob() is (iirc) not sorted in any way on macos. I would prefer alphanumerical sort by name as it is stable across OSs.

Parallelization is optimization so I think «make it right, then make it fast» is sound advice.

Re: How to teach Git

#55

Post by detaro »

Double_a_92 wrote: post #34
detaro wrote: post #8

Earlier quoted context omitted.

Staging puts things in the box, commit closes the box, puts it on the pile with the other boxes, and gives you a new empty staging box.

But why is it an extra step? It's basically just a "longterm" selection of what you want to commit.

Because you not always want to put everything in the box (and if you do, there's a shortcut to do it), and "git commit file1 folder/folder/ * .cpp folder/folder/ * .h ..." for a complex set would be annoying and require you to mentally keep track of it from the beginning.

Many beginners will start by always doing "git commit -a" and that's fine, as long as they know there's an alternative once they need it.

Re: How to teach Git

#56

Post by tux1968 »

Gys wrote: post #9
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?

For simple projects (like ppl experimenting with git) you will always want to save all changes. So why stage first ?

Not everyone stays a beginner forever, and it's nice to have a tool that doesn't play to the lowest common denominator. It's really not that hard to just do a "git commit -a" if you want to avoid staging.

Re: How to teach Git

#57

Post by benwaffle »

jamesb93 wrote: post #27
diegoperini wrote: post #3

An honest criticism: If I had trouble with understanding the reason behind add->commit->push workflow, I would definitely have no idea what this article talks about when it says things like "merge, rebase, diamond shape". The flow chart looks almost exactly the same for "pull" and "pull --rebase". The only difference between the charts is the wording which has no meaning at all for a newbie.

It sounds stupid but something that really simplified git to me as an absolute beginner about a year ago was the fact that it doesn't exist on GitHub. Knowing that git was just something that sat in the folder on your filesystem and monitored changes took away the notion that there is some kind of sync between your remote and local. Working just on my own laptop made me realise how intuitive all the commands and stra…

I wouldn't say it monitors the directory, because there is no git daemon running. Git just looks at the changes whenever you run a git command

Re: How to teach Git

#58

Post by e40 »

navinsylvester wrote: post #52

No one is appreciating the effort and a different take here. Let me congratulate the author on job well done. There are people who love illustrated explanation and for those these are perfect. This is just meant as a template which others can use to build the illustrated material and in no way a comprehensive git tutorial.

I completely agree. I've seen a lot of these, and this one is simple, to the point and easy to understand.

Re: How to teach Git

#59

Post by [deleted] »

Ajedi32 wrote: post #47
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` 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.

[deleted]

Re: How to teach Git

#60

Post by ahartmetz »

And here is something to take the garbage quality of Git manpages with some humor

https://git-man-page-generator.lokaltog.net/

"git-eliminate-head eliminates all downstream heads for a few forward-ported non-counted downstream indices, and you must log a few histories and run git-pioneer-object --pose-file instead. [...]"

Post reply on HN