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

Beej's Guide to Git

beej.us

Post reply on HN
Print view View original

291–300 of 318 posts

Re: Beej's Guide to Git

#291

Post by raju »

valenterry wrote: post #84
elevatedastalt wrote: post #24

I regularly conduct 2 hr long "Intro to the Git Data Model" courses at my workplace (1-2 times a year). I literally take them into the .git directory and unzip the files to show how everything is just plain text representation of basic data structures. It's honestly cool to see it click in their heads. We have a basic Git cookbook we share with any new joinees so that they start committing code, but most of them just…

Share your video!

Not the OP, but I've been teaching along similar lines. I've done it a couple of times at conferences—here's one of the versions: https://www.youtube.com/watch?v=8Q-frNO-yps

I've also blogged about it

- https://looselytyped.com/blog/2014/08/31/gits-guts-part-i/

- https://looselytyped.com/blog/2014/10/31/gits-guts-part-ii/

Re: Beej's Guide to Git

#292

Post by raju »

nomilk wrote: post #78
elevatedastalt wrote: post #24

I regularly conduct 2 hr long "Intro to the Git Data Model" courses at my workplace (1-2 times a year). I literally take them into the .git directory and unzip the files to show how everything is just plain text representation of basic data structures. It's honestly cool to see it click in their heads. We have a basic Git cookbook we share with any new joinees so that they start committing code, but most of them just…

Is there a copy/video of your talk, or a similar one you recommend?

Posted this comment https://news.ycombinator.com/item?id=42961468

Happy to get any feedback.

Re: Beej's Guide to Git

#293

Post by raju »

beej71 wrote: post #30

Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej

Let me start by saying this is wonderful work. Thank you for creating such a comprehensive resource. I haven't read through it all, but one thing did catch my eye.

Section 5.1 (https://beej.us/guide/bggit/html/split/branches-and-fast-for...)

> The default branch is called main.

> The default branch used to be called master, and still is called that in some older repos.

This is not true. Git still defaults to `master`, but allows you to change the default (for future `git init` invocations via `git config --global init.defaultBranch `)

See https://github.com/git/git/blob/bc204b742735ae06f65bb20291c9...

Again, thank you. If I find anything else, I will be sure to post here.

*Update*: I also feel that referring to "older repos" sends the wrong message. *GitHub* decided to make this change, causing others to follow, and finally Git itself allows for the aforementioned configuration, but it has little to do with _newer_ or _older_, but rather preference.

Re: Beej's Guide to Git

#295

Post by globular-toast »

HdS84 wrote: post #279
globular-toast wrote: post #161

Earlier quoted context omitted.

There is one fundamental piece missing in your description of git that I think is the main reason people don't understand it. You have described a single DAG, but in git there are multiple DAGs . This is what it means to be a distributed version control system. In my experience people come to git and start using it with the centralised paradigm in their heads: that there is one repo and one DAG etc. They think that t…

My problem is that I always use git as a central server. Except that one time when our internal git was down and we used it peer to peer for a day. Honestly, using USB sticks for that would also have been okay.

> Honestly, using USB sticks for that would also have been okay.

Right! People often forget git was designed specifically for Linux kernel development which is done by a loosely-knit global base of developers. There are much simpler solutions if you can actually live with exchanging USB sticks.

One nice thing is only needing to know one tool for both open source and centralised development, though. It can seem a little odd if you don't do any open source at all, though.

Re: Beej's Guide to Git

#296

Post by bicolao »

juped wrote: post #276
diggan wrote: post #194

Earlier quoted context omitted.

> I didn't even know git switch existed, let alone git checkout was considered the old alternative. I feel old. I don't think "git checkout" is considered the "old alternative", at least not yet. Last time I checked, `switch` is still experimental, I haven't even considered moving away from the workflows/commands I first learned when I picked up Git ~15 years ago. Everything I want to do still works exactly the same…

switch/restore are not experimental in that sense, they're experimental in the sense that they're not guaranteed stable so don't rely on them for scripts or something (I occasionally tell myself I should adopt them and get them stabilized, but then don't do it)

It was experimental to allow the developers to tweak UI, including breaking backward compatibility if needed. But I left Git shortly after these were added. I guess nobody picked this up to finish the job (even by just removing the experimental status, since nothing has changed for years and I assume nobody complained about them).

Re: Beej's Guide to Git

#297

Post by andrewflnr »

juped wrote: post #277
scrapcode wrote: post #26

I can't help but feel that Git has completely missed the forest through the trees that you can make a 30+ part guide explaining how to use it.

Why are programmers so vehemently angry over the fact that a complex tool which does complex things to a complex data structure might have some complexity to it?

The data structure isn't that complex. Most of the things we want to do to it aren't that complex. And yet... https://xkcd.com/1597

Re: Beej's Guide to Git

#298

Post by sangnoir »

ericholscher wrote: post #199
aidos wrote: post #148

Earlier quoted context omitted.

Not wrong, but since you’re mentioning vim in the context of git, might be worth adding :cq as a way to exit with a non-zero status to prevent git from finishing the commit / operation.

I usually use :q! which seems to do the same thing

That only works if the edit buffer is blank or only has commented out lines. In other cases, such as when you're trying to cancel a `git commit --amend` that loads up the last commit message in your buffer, :q! will not cancel the commit, but :cq will.

Re: Beej's Guide to Git

#299

Post by beej71 »

raju wrote: post #293
beej71 wrote: post #30

Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej

Let me start by saying this is wonderful work. Thank you for creating such a comprehensive resource. I haven't read through it all, but one thing did catch my eye. Section 5.1 ( https://beej.us/guide/bggit/html/split/branches-and-fast-for... ) > The default branch is called main. > The default branch used to be called master, and still is called that in some older repos. This is not true. Git still defaults to `maste…

Hrm. I didn't realize. I unset `init.defaultbranch` and it uses `master` and prints a block of hints.

> hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and 'development'. The just-created branch can be renamed via this command:

That's going to make it more "interesting" to write the fix, that's for sure.

Thanks!

Re: Beej's Guide to Git

#300

Post by beej71 »

junebash wrote: post #41
beej71 wrote: post #30

Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej

Just a quick shout-out; I was one of the many many students you taught at Lambda School, and just wanted to say your instruction was one of the highlights of my time there. Thanks for doing what you do!

You're welcome! :)
Post reply on HN