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

201–210 of 318 posts

Re: Beej's Guide to Git

#201

Post by wruza »

ajross wrote: post #166
wruza wrote: post #110

Earlier quoted context omitted.

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…

Literally every one of those questions can be trivially googled. (In previous generations and fora, this is where you'd be mocked with LMGTFY links). You just, to continue to embrace the frame, don't want to do the work. If you insist on memorizing commands for all these tasks (of which there are many ), indeed, you're going to struggle and decide you need a 30 section guide. But you don't, and want to whine about it…

First I didn’t understand git, now I don’t want to do the work. Then I do the work but it doesn’t work. Feel free to LMGTFY me on the last question. Do you know the answer? Is there an answer? Can you do the work?

What a stupid series of sentences this is for a piece of software we have to use daily. Even talking about it feels cringe.

Re: Beej's Guide to Git

#202

Post by imcritic »

nomilk wrote: post #75
dijit wrote: post #3

Well, what's terrifying is that the guide is so long . I am aware that beej's guides are typically quite comprehensive, but the vast nuances of git truly eluded me until this. I guess Jujitsu would wind up being a much slimmer guide, or at least one that would be discoverable largely by humans?

The guide is comprehensive, on the other extreme, this one-pager contains 90% of git commands you'll ever need: https://wizardzines.com/git-cheat-sheet.pdf

It is quite bad and uninformative, you better not spread it.

Re: Beej's Guide to Git

#203

Post by lucasoshiro »

o11c wrote: post #51
lucasoshiro wrote: post #25

Earlier quoted context omitted.

I did it once, I was indeed really nice, and the discussion that we did after was very cool. I put in the last slide of the presentation some questions for my colleagues answer based on the Git data model, e.g.: "Can we move a commit to another branch?" or "What guarantees that we don't have cycles in the commit graph". I was really satisfying that people came out thinking Git, not only using it!

That last question is a cryptography question in disguise; the answer is "the fact that SHA-1 collisions are still impractical for most people".

Correct!

Even though SHA-1 collision were achieved, they are impractical and we can make the assumption that "if two objects has the same hash, they are the same".

To have a cycle, both commits involved would need to have the hash of the other, which is impossible: the hash of a commit is based on its content, its content contains the hash of its parent.

We could only have a cycle here if we create two commits created after two arbitrary hashes.

Re: Beej's Guide to Git

#204

Post by nomilk »

imcritic wrote: post #202
nomilk wrote: post #75

Earlier quoted context omitted.

The guide is comprehensive, on the other extreme, this one-pager contains 90% of git commands you'll ever need: https://wizardzines.com/git-cheat-sheet.pdf

It is quite bad and uninformative, you better not spread it.

I really like it. Which bits do you dislike?

Re: Beej's Guide to Git

#205

Post by lucasoshiro »

elevatedastalt wrote: post #27
lucasoshiro wrote: post #25

Earlier quoted context omitted.

I did it once, I was indeed really nice, and the discussion that we did after was very cool. I put in the last slide of the presentation some questions for my colleagues answer based on the Git data model, e.g.: "Can we move a commit to another branch?" or "What guarantees that we don't have cycles in the commit graph". I was really satisfying that people came out thinking Git, not only using it!

Exactly, and it's such a high success rate! This is precisely why it enrages me when all HN discussion about Git devolves to the same stuff about how it's complex and this and that. A technical person who has general sense about basic data structures (Leetcode nonsense not needed) can be taught Git in under 2 hours and they will retain this knowledge forever. If you can't invest that little time to learning a tool yo…

Perfect!

Git is only a directed graph with the adjacencies stored as hashes. Everything else is just tooling around that data structure. No problem using Google to find the commands (the Git CLI is very inconsistent...) but if you know what you want to do with that data structure you can find precisely the commands for that.

Re: Beej's Guide to Git

#206

Post by imcritic »

riffraff wrote: post #111
stephen_g wrote: post #16

Earlier quoted context omitted.

I think it's probably the opposite, Git has amassed a lot of complexity because it's been adapted to being a tool that is able to can satisfy the majority of requirements. I've never found that I need to touch most of it in the 15 or so years I've been using it, but it's there if your project needs it.

Git was always confusing to use. There's a reason it has gained a "switch" command, and that's because the "checkout" command was confusing, while being there from the beginning. Probably you've been using it for ten years or more at this point and have internalized it, but when it came out git felt way more confusing than other VCSs. Compare git diff with hg diff for example.

Git is wrong in some regards: they introduce an entity "branch", but it is not stored properly, it's like virtual data.

The proof that there are really no branches in git's storage is a simple task that's not achievable in git:

suppose you had some branch, but you don't remember it's name, then you branched off and issued some commits. Now there's no way to get a git history consisting of just the commits introduced since you branched off.

Re: Beej's Guide to Git

#207

Post by wruza »

MrJohz wrote: post #181
ajross wrote: post #166

Earlier quoted context omitted.

Literally every one of those questions can be trivially googled. (In previous generations and fora, this is where you'd be mocked with LMGTFY links). You just, to continue to embrace the frame, don't want to do the work. If you insist on memorizing commands for all these tasks (of which there are many ), indeed, you're going to struggle and decide you need a 30 section guide. But you don't, and want to whine about it…

> Literally every one of those questions can be trivially googled. (In previous generations and fora, this is where you'd be mocked with LMGTFY links). You just, to continue to embrace the frame, don't want to do the work. I find this an odd statement. I mean, no, I don't want to do the work! Not if it isn't necessary in the first place. Take staging (or the index, because another of Git's foibles is poor naming conv…

Jujutsu

Whew, just from the intro this feels like a breath of fresh air. Probably gonna migrate to it right after finishing the tutorial. Thanks for mentioning!

https://github.com/jj-vcs/jj

Re: Beej's Guide to Git

#208

Post by necauqua »

forrestthewoods wrote: post #129
sunshowers wrote: post #123

Earlier quoted context omitted.

Why not switch forward to Jujutsu? It's simpler and more powerful than Git.

I've been using Jujutsu a little and over the weekend lost a bunch of files. I'd been working happily in an anonymous branch. I had a bunch of content in a thirdparty folder that was hidden by .gitignore. I couldn't figure out how to merge my anonymous branch into master. Somehow wound up on the old master and it deleted all of my gitignored files. Then jj status got totally fubar and couldn't complete in under 5 min…

While I understand your predicament, consider not giving up on jj just yet because of this.

It is _exceedingly_ hard to lose files in jj, it's actually emotionally frustrating reading the line "most important thing [..] is to never ever delete file" because that's the whole shtick in jj with the oplog and whatnot - so something like nuking secrets completely from a jj repo is a bit of a chore.

Can you file a bug at least? A repro of some sort?. Or at least show us what is it what you did, `jj op log` might be enough to deduce what happened.

Also check out `jj op log -p`, your files might very well be in history, especially if, as you said, jj status took a long time (presumably snapshotting those files that got lost)

Re: Beej's Guide to Git

#209

Post by wruza »

globular-toast wrote: post #127
wruza wrote: post #103

Earlier quoted context omitted.

I’ve seen tortoise users break their repo, struggle to understand the issue and then push it through, making it everyone’s problem. Git language is screwed, you cannot unscrew it with a right-click gui because you basically click some latin-looking hieroglyphs that you don’t know either way.

I highly doubt tortoise or any tool can "break" a repo. This might be a sign that you don't understand git either. Now I'm sure it can lead to people who don't know what they're doing doing the wrong thing, but if they're allowed to push somewhere and make it someone else's problem, that's not their fault. They've been forced to use git, so there should be someone else who actually understands git.

“Break” doesn’t mean repo integrity corruption. It means that you try to merge a branch, and it shits itself with hundreds of conflicts that shouldn’t appear and/or has changes that may partially revert the progress made by other merges.

if they're allowed to push somewhere and make it someone else's problem, that's not their fault

What? This made zeroest sense of the day. Like, I should walk to their desk and check if a feature branch is okay to push or what?

Re: Beej's Guide to Git

#210

Post by jayd16 »

Looks amazing. I don't see anything on Large File Support though. As annoying as it is, it's a hard requirement for some parts of the industry (especially games) and worth a mention.
Post reply on HN