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

151–160 of 318 posts

Re: Beej's Guide to Git

#151

Post by abenga »

wruza wrote: post #110
ajross wrote: post #43

Earlier quoted context omitted.

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…

This doesn’t work. Look: Commits are sets of files. They form a tree. A branch is a named location in this tree. The index aka staging area is a pre-commit that has no message. Workdir is just workdir, it doesn’t go in the repo unless you stage it. HEAD is whereafter commit will put new changes. Do I understand git? Seems like yes. Let’s run a quiz then! Q? A. How to make a branch? Git branch -a? Git checkout -b --ne…

Skill issue, it seems.

Facetiousness aside, the things you do often, you learn once and you don't really have to remember/think when doing them. Most of the esoteric operations are mostly unnecessary to burden yourself with until you actually have to do them, when you just read the documentation.

Re: Beej's Guide to Git

#152

Post by rtldg »

verandaguy wrote: post #34
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.

Eh, yes and no. Git porcelain stuff's plenty good for probably 95% of users. `rebase -i` comes with a guide on which commands do what, and you could write a couple of paragraphs about how to format `git log`'s output with your own preferences and tradeoffs -- and porcelain usually includes stuff as eclectic as `git gc`, `git fsck`, and `git rev-parse` by most accounts. Git plumbing's definitely a bit more obscure, an…

With 'gitk' I'm not sure I'll ever have to learn how to use 'git log'. A Good Enough preinstalled GUI is too convenient

Re: Beej's Guide to Git

#153

Post by forrestthewoods »

crabbone wrote: post #146
forrestthewoods wrote: post #144

Earlier quoted context omitted.

You could have marked the file as not read-only and later reconciled. Or you could have checked the file out of Perforce. You would have had a merge conflict either way. I mean I haven't even talked about how Git can't handle large files. And no Git LFS doesn't count. And Git doesn't even pretend to have a solution to file locking. I'm not saying Perforce is perfect. There's numerous things Git does better. But Perfo…

So, there's a difference between how problems are common, how many of them are there, and how hard it is to deal with them. So, is it possible to deal with Perforce marking files read-only? -- Yes. And it's not complicated, but the whole idea that that how the system should work is stupid. The problem is, however, exceptionally common. In my days working with Perforce there hadn't been a day when this problem didn't…

I appreciate your hatred of Perforce. But I think you've let your hatred blind yourself to the argument I actually made. In my original comment I made two arguments:

1. Git is complicated 2. Perforce is so simple to use that I can teach an artist or designer who has never even heard of source control how to use it in 10 minutes.

Then you came in and said the way Perforce handles read-only files is stupid. You know what, I agree! That's a solvable problem. If Perforce wasn't acquired by a private equity firm maybe they'd actually work to make it better. Alas.

This isn't about Git vs Perforce. I post in all of these Git HN threads because I desperately want people to realize that Git sucks ass and is actually really bad. WE COULD HAVE SOURCE CONTROL THAT DOESN'T SUCK. IT'S POSSIBLE. I'm not saying that Perforce is that solution. I'm saying that Mercurial and Perforce are existence proofs that certain things are possible. Source control doesn't have to be complicated! It doesn't have to have footguns! It doesn't need a 189 page guide!

Re: Beej's Guide to Git

#154

Post by zelphirkalt »

20k wrote: post #64
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

Learning it like this makes one learn the concepts though and build something closer to an actual understanding. I have seen people struggle with understanding what git does or with making fine grained commits or mostly atomic commits a lot, especially GUI users, because many of them do not have the underlying concepts understood well enough.

Re: Beej's Guide to Git

#155

Post by tathagatadg »

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/

Came here to see if it was the same person, though I felt very sure with the throwback web design - back when each page had its character, and you had to save the page for offline reading so that Dad wasn't pissed at the phone bill! And when the code worked - it was validation against all the previous failures (and rejections) in life! Oh the joy of sending message from one computer to the other!

Thank you Beej.

Re: Beej's Guide to Git

#156

Post by PhilipRoman »

I feel like a lot of the problems with Git UI come from needing to interact with a "normal" filesystem. I'd much rather have a FUSE/9p mount with all commits, index, etc. available as directories, where they can be read, written, diffed, etc.

Re: Beej's Guide to Git

#158

Post by tonyedgecombe »

zelphirkalt wrote: post #154
20k wrote: post #64

Earlier quoted context omitted.

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

Learning it like this makes one learn the concepts though and build something closer to an actual understanding. I have seen people struggle with understanding what git does or with making fine grained commits or mostly atomic commits a lot, especially GUI users, because many of them do not have the underlying concepts understood well enough.

I think you could use a CLI and still not really understand the core concepts.

Re: Beej's Guide to Git

#159

Post by n_plus_1_acc »

maccard wrote: post #138
rswail wrote: post #115

Earlier quoted context omitted.

Sounds like you need a pre-commit hook to check.

Pre commit hooks aren’t enforcable. People need to opt in to them, and the people who opt in to them are the people who will check for passwords before they commit.

Server-side pre-recieve hooks are better

Re: Beej's Guide to Git

#160

Post by jeroenhd »

20k wrote: post #64
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

I disagree. Version control is kind of a pain, you need to understand some of the underlying concepts or you'll break your git repo in spectacular ways.

The command line isn't that hard to use if you've ever used the command line before. Beginners trying to learn git and command line at the same time (which is very common) will get utterly confused, though, and for a lot of beginners that's the case. The only difficult part with git over the command line is fixing merge conflicts, I'd recommend anyone to use any IDE rather than doing that manually.

No IDE will be of any help for getting back to normal when you get into a detached HEAD state, which IDEs will gladly let you do if you click the right button.

Post reply on HN