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

Oh Shit, Git

ohshitgit.com

Post reply on HN
Print view View original

221–230 of 237 posts

Re: Oh Shit, Git

#221

Post by epistasis »

sreevisakh wrote: post #216
epistasis wrote: post #106

Earlier quoted context omitted.

I think the underlying model is fantastic, but the names for operations, and how they are grouped, are somewhat ad hoc. The idea of a directed graph of file system snapshots is pretty intuitive. Add in branches as pointers to locations in that graph. This is a fantastic model for source control. However the operations that stage a potential update to the graph of snapshots is prettt confusing. The "index" is a terrib…

> I think the underlying model is fantastic The well-documented underlying model used to confuse me a lot - especially for operations like merging, rebasing (squash, reorder, ...), cherry picking, etc. They started to make sense only when I realized that git uses diffs/patches to propagate changes between unrelated commits. While the on-disk format is purely snapshot-based, the tool itself is a hybrid. As far as I ca…

Agreed, the first step is realizing that the data structure is a graph of snap shots. And then a lot of the primary operations are about calculating deltas between arbitrary commits, and the applying those deltas elsewhere.

Re: Oh Shit, Git

#222

Post by omegalulw »

gpspake wrote: post #108

I find people are religious about being git cli purists and only interacting with it in this black box (the terminal). On top of that a lot of people stop learning git after add commit push pull branch and merge so concepts like rebasing and cherry picking are scary. In this day and age we have state of the art GUI tools that change the game and allow git users to see and interact with the state of a git repository i…

What GUI tools did you have in mind? git CLI is spectacularly good, GUIs tend to just make things slow and get in your way. With CLI you will also get the same experience on every platform, and even when you SSH.

Re: Oh Shit, Git

#223

Post by kingboss »

nocman wrote: post #195
at_a_remove wrote: post #188

Earlier quoted context omitted.

You have made my point for me. "This command manages the information recorded in the reflogs." WHAT? Of course everything has an obvious name if you have to learn everything about it. The point I am making is that the name ought to be obvious before you have to learn everything about it. "Undo" is a reasonable choice if you barely understand what git is for and "reflog" is not. Once you master a system and agree to a…

You have made my point for me. There is a minimum level of knowledge you need to know to use git. It is not as straightforward as, say a simple text editor. The problem git is solving is more complex than that, and therefore understanding how to use it requires investing a significant amount of time in learning how it works. If I was going to go back to my previous commit, I would use "git reset" to go back to the co…

No. You are being deliberately obtuse. There is no way to argue that "reflog" is something that is intuitive or that should be known by somebody who just wants to commit on branches and merge them sometimes. Which is what most people need git for. If the minimum level of knowledge to operate a car is to know what every piece of it does and how to reassemble it from scratch the designer of said car hasn't been doing his job. This is exactly the problem with git. You wanted 2 branches and now you have to understand the that the underlying system is actually a filesystem cause that's what Torvalds was used to.

Re: Oh Shit, Git

#224

Post by nocman »

kingboss wrote: post #223
nocman wrote: post #195

Earlier quoted context omitted.

You have made my point for me. There is a minimum level of knowledge you need to know to use git. It is not as straightforward as, say a simple text editor. The problem git is solving is more complex than that, and therefore understanding how to use it requires investing a significant amount of time in learning how it works. If I was going to go back to my previous commit, I would use "git reset" to go back to the co…

No. You are being deliberately obtuse. There is no way to argue that "reflog" is something that is intuitive or that should be known by somebody who just wants to commit on branches and merge them sometimes. Which is what most people need git for. If the minimum level of knowledge to operate a car is to know what every piece of it does and how to reassemble it from scratch the designer of said car hasn't been doing h…

I'm not being at all obtuse, you just don't agree with me.

Re: Oh Shit, Git

#225

Post by benreesman »

chairmanwow1 wrote: post #35
benreesman wrote: post #24

It always amuses me that when Linus presents git to “the Google audience” they objected to the complexity, those people are in fact elite, but measured against what? The TailScale people? The TS people are ex-Google in some places and early-Nix in others, either way no one to fuck with. I’m frustrated if I take a day to work out some something that Jeff Dean mentioned to, uh, a friend, and it took me a day to work it…

I honestly don’t understand the context around this comment or how it relates to the article

It’s admittedly a snippy, snarky, kind of cryptic comment and I probably deserve more downvotes than I got on it.

In a more measured tone: there is, in my opinion, a kind of creeping anti-intellectualism that’s been slowly-but-surely gaining ground on HN for the last 5-ish years.

We used to just really openly admire and respect iconic pros in this business, we used to openly acknowledge that some of the software work we talk about is pretty friggin elite and few of any of us will ever even work on some of it.

Whether it’s Linus or the TailScale pros or John Blow, I’ve seen people get gang-tackled by the “no one ever uses this LeetCode stuff in a real job” crowd repeatedly in the last week.

Knowing how to use “git reflog” to do surgery on a fucked-up repo isn’t necessary every day, but when you need it, you need it bad, and there’s nothing outdated about how knowing how the damned tools work.

Re: Oh Shit, Git

#226

Post by saboot »

olvy0 wrote: post #155
layer8 wrote: post #100

Earlier quoted context omitted.

https://stackoverflow.com/questions/2100907/how-to-remove-de...

I second the recommendation to use git rocket filter [1] from this link. A guy in our team committed a big file unnecessarily into the repo which already had a year's history behind it, and it was only a month later when I found out. git rocket filter filtered it in a few seconds. Since all team members had already gotten it, I ran it on all their repos to verify it's gone, and ran the usual git gc incantation [0] to…

Thank you, this looks promising

Re: Oh Shit, Git

#227

Post by allarm »

dahart wrote: post #131
gpspake wrote: post #108

I find people are religious about being git cli purists and only interacting with it in this black box (the terminal). On top of that a lot of people stop learning git after add commit push pull branch and merge so concepts like rebasing and cherry picking are scary. In this day and age we have state of the art GUI tools that change the game and allow git users to see and interact with the state of a git repository i…

> I find people are religious about being git cli purists […] we have state of the art GUI tools I would humbly suggest you avoid framing it that way, even if you believe it’s true. From someone who is only sometimes a cli advocate, my immediate assumption is that your opinion here may be formed out of naïveté and a bit of fear of the cli. Please note I’m actually quite a fan of using various GUI tools for basic git…

Have you tried Magit? It’s a common opinion that it’s very close to cover everything what you can do with git from cli.

Re: Oh Shit, Git

#228

Post by brainburp »

dahart wrote: post #193
canaus wrote: post #151

Earlier quoted context omitted.

I'd really like to know what mess people make when they don't rebase. I've found that using merge gives a readable trail of when something was merged, whether that be from a branch's original branch, or if you're merging into another branch. Rebasing just seems to cause a lot more headache when something doesn't go perfectly correct in between commits.

FWIW, I was mainly referring to making local branches presentable and/or just organizing things, not to rebase as a merge strategy. Don’t assume that rebase always means moving the local branch to the head of main, and don’t assume that rebase and merge are interchangeable. There are a lot of ways to rebase.

That's what I thought the discussion was about, locally 'clean' commits. In this context Rebase is so much more useful. I recently had to use the 'unto' option of the rebase command. 'unto' may show someone that they didn't really understand rebase though they could use the simple form of it, rebase -i x.

Re: Oh Shit, Git

#229

Post by pjmlp »

Jedd wrote: post #217
pjmlp wrote: post #157

Earlier quoted context omitted.

The alternatives weren't required for collaboration in Linux development.

Yes, but again, the number of people collaborating on Linux kernel development is truly tiny. I think perhaps you're over-estimating the network effect for VCS's -- having multiple version control binaries on your machine is low cost, and aliases can, up to a point, give you a consistent interface to them all. The highly sophisticated demographic of kernel developers would not have been at the pub insisting that thei…

Bitkeep wasn't free beer and its adoption was widely controversial, until Git was born given their change of heart.

Re: Oh Shit, Git

#230

Post by michaelcampbell »

canaus wrote: post #151
dahart wrote: post #131

Earlier quoted context omitted.

> I find people are religious about being git cli purists […] we have state of the art GUI tools I would humbly suggest you avoid framing it that way, even if you believe it’s true. From someone who is only sometimes a cli advocate, my immediate assumption is that your opinion here may be formed out of naïveté and a bit of fear of the cli. Please note I’m actually quite a fan of using various GUI tools for basic git…

I'd really like to know what mess people make when they don't rebase. I've found that using merge gives a readable trail of when something was merged, whether that be from a branch's original branch, or if you're merging into another branch. Rebasing just seems to cause a lot more headache when something doesn't go perfectly correct in between commits.

This is my reaction based on experience too. I find that in most companies I've worked at that there are generally 2 camps; one is the "I want history to track what I've actually done; good, bad and ugly", the other is "I don't want to wade through 1000 "typo" commits - they should be pretty and streamlined".

I fall into the former camp, but others (who I respect) fall into the latter.

Post reply on HN