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

241–250 of 318 posts

Re: Beej's Guide to Git

#241

Post by curiousinspo »

jeroenhd wrote: post #165
dekhn wrote: post #66

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…

Git is absolutely terrible for large files, especially binary files. That's why git LFS rarely ever uses git as a storage mechanism. I know programmers like everything to be in version control, but AI models and git just aren't compatible.

[dead]

Re: Beej's Guide to Git

#242

Post by maccard »

diggan wrote: post #198
maccard wrote: post #142

Earlier quoted context omitted.

> Find your last entry before the rebase using the reflog and reset your local branch to that entry. You shouldn’t ever need to go to the reflog unless you’re in an exceptional case, and fit makes it very very easy to get into that exceptional case.

> You shouldn’t ever need to go to the reflog unless you’re in an exceptional case If "loosing your work and it's not in the git log" isn't an exceptional case, what exactly is a "exceptional case"?

> If "loosing your work and it's not in the git log" isn't an exceptional case, what exactly is a "exceptional case"?

Losing your work should be exceptional. It's very, very easy to fuck a rebase up, and rebasing is (like it or lump it) a common operation. You shouldn't one step away from an exceptional case from a daily operation.

Re: Beej's Guide to Git

#243

Post by Izkata »

Izkata wrote: post #80
forrestthewoods wrote: post #73

Earlier quoted context omitted.

Honestly? I’m not sure. Here’s the problem: 1. it’s possible to get into a bad state 2. it’s not clear what exactly that state is 3. it’s not clear how you got into that state 4. it’s not clear how to get out of it I understand Git reasonably well. I know a good bit how it works under the hood. When I have a gitastrophe I rarely understand what I did wrong and how to avoid it in the future. Here’s a recent post from…

Well first, that's not git, that's some other GUI giving its own interface to git. The majority of the time my co-workers have a git problem, it's because their GUI tool has done something weird without telling them exactly what it did - one of theirs has a "Sync Branch" button which he'd click on whenever the IDE highlighted it, and I have no idea what that's even supposed to do, but I think it was some sort of reba…

That (4) in my comment was supposed to be (5), way too late to fix now.

Re: Beej's Guide to Git

#244

Post by maccard »

diggan wrote: post #196
maccard wrote: post #143

Earlier quoted context omitted.

How do switch to a branch? (Note that you need to fetch before you switch. Also switch is experimental but it’s not really) How do I undo a change and get it to other people on the team? - follow up, What happens if someone has made an unrelaydx change since? - someone has committed an enormous change and I want the commit immediately after it but the enormous change doesn’t affect me. How do I get that single file w…

I'm aware of how to do most of those things in git, but that probably says more about me than git. What I'm curious about though, since I basically entered the software developer workforce just as Git became mainstream and GitHub became popular, how would you do those things with the alternatives at the time; SVN, Mercurial, Perforce and the rest? Would it be easier or harder? Would it work better/worse in a sync/asy…

> without centralized servers?

Git is complicated _beacuse_ of this. The defaults are tuned for this. But, most people don't need this. I'm sure there are people out there who set an upstream to their coworkers PC and clone a branch from them, merge it with their work and then someone else takes that and is saved a bunch of work because the commits all line up, but for every 1 of those people there are probably 100,000 who push and pull to a centralized forge, and pay the complexity cost for the distributed workflow.

> but they almost always fail to put forward some simpler alternative that can handle the same things. Is git actually accidentally complicated or purposefully complicated because the topic at hand is kind of complicated?

Git is complicated because it's got poor defaults, an unintuitive cli, and is designed for distributed workflows (I've never worked anywhere that has used a distributed workflow, fwiw). I can sit someone down with perforce for 15 minutes and basically never have to interact with them on it again. It's _so_ much simpler - because it's centralized. It has some baggage, is definitely not perfect (and it costs an absolute bomb). Mercurial is another example of something that is much, much easier to use and work with. I wish mercurial won, honestly.

Re: Beej's Guide to Git

#246

Post by beej71 »

patchd wrote: post #189
beej71 wrote: post #30

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

Not wrong, but worth mentioning. I really found git worktrees to be crucial to my workflow and have heard very few people mention them or even know they exist. Excellent way to keep your branches from getting their streams crossed without the headache of dealing with stashes.

I was on the fence about this one. Yes, it's totally useful, but I swore after writing my comprehensive C guide I would never write a comprehensive guide again. :) So I try to decide where to cut people loose to use other resources once they have the foundation.

All that said, they are really useful. And, honestly, the chapter would be pretty short to get basic usage down... but also if you've gotten as far as grokking how branches work, it's pretty easy to pick up worktrees. The fact that lots of people don't know they exist is points for adding it just for that reason alone.

I'll mull it over. :) Cheers!

Re: Beej's Guide to Git

#247

Post by diggan »

maccard wrote: post #242
diggan wrote: post #198

Earlier quoted context omitted.

> You shouldn’t ever need to go to the reflog unless you’re in an exceptional case If "loosing your work and it's not in the git log" isn't an exceptional case, what exactly is a "exceptional case"?

> If "loosing your work and it's not in the git log" isn't an exceptional case, what exactly is a "exceptional case"? Losing your work should be exceptional. It's very, very easy to fuck a rebase up, and rebasing is (like it or lump it) a common operation. You shouldn't one step away from an exceptional case from a daily operation.

Powerful tools have powerful consequences, case in point: with `rm` you're always one mistake away from blowing away large parts of your work.

Re: Beej's Guide to Git

#248

Post by maccard »

crabbone wrote: post #212
maccard wrote: post #139

Earlier quoted context omitted.

> I don't know why Git won the VCS contest Because GitHub offered free git hosting, and heroku came along and offered free hosting that was pretty much point and go. Combined, you all of a sudden went from needing a sysadmin and two servers (this was pre containers), and the sysadmjn skills to operate SVN and your web app, to “it’s now free and it auto deploys when I commit”.

Bitbucket offered free Mercurial hosting before GitHub even existed, if memory serves. And it's all but dead. And, I don't know if GitHub succeeded because of Git or the other way around.

This war was over around about the time I started, but my take on it is that it's all a bit intermixed and Mercurial lost because bitbucket caved and did git hosting [2], but git won beacuse of github and heroku [1][2]

[1] https://www.koyeb.com/blog/herokus-free-tier-legacy-the-shou... [2] https://blog.gitbutler.com/why-github-actually-won/

Re: Beej's Guide to Git

#249

Post by crabbone »

maccard wrote: post #132
crabbone wrote: post #120

Earlier quoted context omitted.

Not at all. Not in the least. The worst part about Git is the bad defaults. Seconded only by mismanaged storage. Or maybe being designed for the use-case most of its users will never have. Or maybe horrible authentication mechanism. Or maybe the lack of bug-tracker or any sensible feedback from its developers. None of this can be helped by the GUI. In fact, beside Magit, any sort of front-end to Git I've seen is hand…

I use the IntelliJ family of IDEs and the number of times I’ve had to reach for the cli for day to day use is incredibly close to 0. It handles GitHub auth, PR’s, branching and merging, rebase, and local branch switching pretty much effortlessly

In my experience, people who use Intellij family of IDEs have very limited understanding of how anything in their computers work. They are hired to "write Java" or something similar, and beside "writing Java" they know virtually nothing and aren't expected to know anything.

I used to work for a large company in the ops department, where a significant portion of my day was spent walking between cubicles and fixing the dev. environment of Intellij IDE programmers. Most of them didn't even know how to find the project they worked on in the filesystem w/o using their editor. The tantalizing task of opening a file with unknown extension was way too much to ask etc.

They would often mess up something in the version control too, using Intellij integration tools, which are really, really bad. But, I don't know whom to blame in this instance. Both the user and the tool were of extremely low quality.

So, if, eg. their Maven build had some sort of an interaction with Git, and they messed up something in their local repository, all work would come to a grinding halt, because they had no idea how to even begin to understand what went wrong.

It's a kind of job where you begin to lose faith in humanity very quickly :D

Re: Beej's Guide to Git

#250

Post by beej71 »

blacksmith_tb wrote: post #232
criddell wrote: post #214

Earlier quoted context omitted.

What's the difference between the one- and two-sided pdfs?

Layout for printing (on paper, for those who still do that) I presume.

Exactly this. There are three main differences:

1. The margins are offset in two-sided, alternating pages. 2. The page numbers are justified alternately left and right in two-sided, and the page header differs left and right. 3. Sometimes a blank page is injected with two-sided to make a chapter start on the correct side of the book.

Post reply on HN