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

61–70 of 318 posts

Re: Beej's Guide to Git

#61

Post by Sxubas »

> The Old Command: git checkout

I didn't even know git switch existed, let alone git checkout was considered the old alternative. I feel old.

To be fair I started learning git a little less than 10 years ago but woah, I can't express how it feels that someone learning git today will be confused of why I use git checkout. Like using old fashioned language.

More on topic, this guide would've been super useful when I was learning. It is really easy to follow and covers common FAQs.

I fondly remember being intimidated by my first merge conflict, aborting it and just doing some workarounds to prevent the conflict.

Re: Beej's Guide to Git

#62

Post by at_a_remove »

beej71 wrote: post #42
boneitis wrote: post #13

I'm really interested and really hoping this is something I can sink my teeth into. I've always had frustrating experiences with trying to wrap my head around git and have to regularly use it at my job. Branching, making commits, and creating pull requests come easy, but beyond that, I know utterly nothing about it.

If you do check it out and there are parts that are confusing, I'd love to hear about it.

This is partially a question and the rest is shameful confession: I had haltingly used cvs as a solo programmer, and when I was suddenly no longer a solo programmer and had to use git, everything went haywire.

I am an Old and we never were taught anything about coding with other people who were also working on the same project. I have had many successful projects but never with another person.

With that as a background, does your guide cover things like:

1) Merging. I was told that merging happens "automagically" and I cannot, for the life of me, understand how a computer program manages to just ... blend two functions or whatever and it "works." Does your guide make sense of this?

2) Apparently there are holy wars (see also vi versus emacs) about the One True Way to ... decide on branches and whatnot. Are there pros and cons laid out anywhere?

3) Everything seems broken down into teensy tiny functions when I look at someone's git repository, just skillions of files all over the place. Is this a git thing, a code repository thing, or simply that, in order for multiple people to work on the same project, everything must be atomized and then reassembled later? What's your opinion?

Re: Beej's Guide to Git

#63

Post by rblatz »

lostdog wrote: post #53
beej71 wrote: post #45

Earlier quoted context omitted.

Out of curiosity, what are the most common foot guns, in your opinion?

Messing up conflicts during a rebase, thinking I did it right, and then finalizing the rebase and losing work that accidentally disappeared. That's my most common mistake at least.

Find your last entry before the rebase using the reflog and reset your local branch to that entry.

The work isn’t lost, it is sitting right there.

Re: Beej's Guide to Git

#64

Post by 20k »

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.

Honestly, 99% of the pain of git is simply because people use it through the CLI. If you use tortoisegit or a visual tool, you don't need to worry about any of this because its self explanatory, and it becomes trivial to use

Learning git like this is honestly just hampering yourself

Re: Beej's Guide to Git

#65

Post by Rendello »

Sxubas wrote: post #61

> The Old Command: git checkout I didn't even know git switch existed, let alone git checkout was considered the old alternative. I feel old. To be fair I started learning git a little less than 10 years ago but woah, I can't express how it feels that someone learning git today will be confused of why I use git checkout. Like using old fashioned language. More on topic, this guide would've been super useful when I wa…

Git switch is fairly new, it first shipped in 2019.

Here's, respectively, a discussion from 2021, and a discussion from a few weeks ago. In the latter, it's brought up that `git switch` is still considered experimental by the docs:

https://news.ycombinator.com/item?id=28024972

https://news.ycombinator.com/item?id=42649858

Re: Beej's Guide to Git

#66

Post by dekhn »

I am not a git fan. After many years (following use of RCS, SCCS, CVS, SVN) I tried it and found that its whole mental model was weird and awkward. I can get around in it but any complicated merge is just painful.

Anyway, the comment I really wanted to make was that I tried git lfs for the first time. I downloaded 44TB (https://huggingface.co/datasets/HuggingFaceFW/fineweb/tree/m...) over 3-4 days which was pretty impressive until I noticed that it seems to double disk space (90TB total). I did a little reading just to confirm it, and even learned a new term "git smudge". double disk space isn't an issue, except when you're using git to download terabytes.

Re: Beej's Guide to Git

#67

Post by matt3210 »

pkage wrote: post #2

I remember reading the excellent Beej's Guide to Network Programming[0] and Beej's Guide to Unix IPC[1] as a teenager, which were incredibly approachable while still having depth—fantastic reads both and very influential on the programmer I ended up being. [0] https://beej.us/guide/bgnet/ [1] https://beej.us/guide/bggit/

I had no idea about IPC! I better go read it!

Re: Beej's Guide to Git

#68

Post by BeetleB »

I'm decent with git (usual flow, merging, rebasing, etc). I'm seriously considering switching over to jujutsu instead of becoming "better" at Git. jj is compatible with git and you can use it while your teammates can also just use git.

Re: Beej's Guide to Git

#69

Post by alberth »

beej71 wrote: post #30

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

I really appreciate you offering the content as a single page.

Thanks for all your guides over the years. Truly invaluable.

Re: Beej's Guide to Git

#70

Post by billdueber »

ajross wrote: post #43
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.

My sense, bluntly, is that if people spent half the effort learning git that they do whining about it, no one would bother making a 30+ part guide just explaining stuff you could find in a man page. Commits are snapshots of a tree. They have a list of ancestors (usually, but not always, just one). Tags are named pointers to a commit that don't change. Branches are named pointers to a commit that do change. The index…

Sigh. Another git thread, another pile of posts telling me that if I would _just do the work_ to understand the underlying data structure I could finally allow myself to be swept up in the _overwhelming beauty_ of the something something something.

The evidence that the git UI is awful is _overwhelming_. Yes, yes, I’m sure the people that defend it are very very very very smart, and don’t own a TV, and only listen to albums of Halloween sounds from the 1950s and are happy to type the word “shrug“ and go on to tell us how they’ve always found git transparent and easy. The fact is that brilliant people struggle with git every single day, and would almost certainly be better served by something that makes more sense.

Post reply on HN