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

151–160 of 237 posts

Re: Oh Shit, Git

#151

Post by canaus »

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…

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.

Re: Oh Shit, Git

#152

Post by at_a_remove »

My first introduction to git was ... well, the professor's solution to not having a place to upload. Given that the vast majority of the students involved had done almost no programming before, it didn't go so hot. I managed.

My first "production" introduction to git was really about someone polishing their resume and chanting magic words at me. Merges ... happen? Who decides whether Bob or Cindy's code is used here? It just happens okay.

Then I bought some books on git and was pretty unhappy with how arcane the naming was. How is "reflog" the correct and intuitive choice for "undo"? Was there something I wasn't understanding? No, I'm just supposed to accept that.

Thankfully, my current programming gig is simple enough that I don't have to look at git. Either eventually sanity will come to the naming of commands or something else will appear, just as it has for every other tool.

Re: Oh Shit, Git

#153

Post by [deleted] »

foobarbaz33 wrote: post #75
ToddWBurgess wrote: post #62

Just curious, are people here still using master or did you migrate to main?

"using master" can imply being a leech. You should replace it with "working with master". "people here" could be interpreted as "you people". Please remove it from your comment.

[deleted]

Re: Oh Shit, Git

#155

Post by olvy0 »

layer8 wrote: post #100
saboot wrote: post #94

What's the solution to "I accidentally committed a GB file and pushed it, now everyone has it"?

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 clean their repo.

[0] https://stackoverflow.com/a/29203553

[1] https://github.com/xoofx/git-rocket-filter

Re: Oh Shit, Git

#156

Post by motoboi »

> # remove the last commit from the master branch > git reset HEAD~ --hard

I see this all the time, this "commits ON a branch" mentality.

My secret to understanding git is: branches are just adresses, labels, pointers, aliases to commits. A branch is just a label pointing to a commit.

So, you don't "remove (or add) a commit from a branch", you change where a branch point to.

Commits are tree nodes, they have a parent and they can have children. If you point a branch to a commit, you can now think of a branch as that commit and its parent commits.

So, `git checkout master` is just `git checkout `. But in a smarter way, as git is storing this as a special reference for you. If you do a `git checkout commit-ref` git will warn you that you are now working in a commit tree without a special name (detached).

Oh, I wrongly "commited to master". Ok, just point master back to the previous commit.

Oh, I want master to point to another point in time. Just find the commit reflecting that point in time and `git switch master; git reset `.

Reset should be called "point the current branch to this commit and make the working tree reflect the state of the code at that commit".

Re: Oh Shit, Git

#157

Post by pjmlp »

Jedd wrote: post #72
pjmlp wrote: post #69

Earlier quoted context omitted.

It dominated the world thanks to Linus cult (their hero can do no wrong), and being required for Linux contributions. I bet git produced by a no name Linus, in isolation not required by any major project, would have hardly been taken any major uptake.

> It dominated the world thanks to Linus cult (their hero can do no wrong), and being required for Linux contributions. I think parent's point is that that demographic is positively tiny , and there were plenty of other serviceable offerings around at the time. The claim stands - git won despite its UX flaws, which does suggest the alternatives, while serviceable, weren't sufficiently fit for purpose.

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

Re: Oh Shit, Git

#158

Post by toxik »

amelius wrote: post #104
toxik wrote: post #76

Earlier quoted context omitted.

You shouldn’t present your own opinions as facts. I find Git intuitive, and it works as I expect it to do. I suspect a lot of people agree since Git became the champion of the DVCS crusades.

Good modern software always offers an undo option. Where is "git undo"?

Ah yes, the classic `rm --undo` saved me so many times. No, command-line interfaces rarely offer undo. The onus is on the user to not do irreversible things when they may need to be reversed.

Git, coincidentally, does have something equivalent to undo history: the reflog.

Re: Oh Shit, Git

#159

Post by wrycoder »

leephillips wrote: post #96
tharkun__ wrote: post #83

Earlier quoted context omitted.

I think this is what can confuse people. We have to face the facts that not everyone will need or be able to grok all of what goes on in git and what makes the car go forward. We can all drive that car still! Take the recursive merging stuff around minute 39. Do I need to know why git's model for merging is so much better and how it works its magic? I don't think so. It's an implementation detail. Do I need to know h…

To a large extent, yes. But when you find yourself stopped at a red light on a steep upgrade, and some idiot behind you decides to wait for the light three inches from your back bumper, things will go better when the light turns green if you have a decent mental model of the physical mechanism of the clutch. Sometimes you want to let those abstractions leak a bit.

I tested a Subaru manual at the dealer a few years back. The exit from the dealership was uphill onto a busy road. So, I stopped and reached for the handbrake.

There was no handbrake.

I managed to work my way back down to the dealership and asked, "Where's the handbrake?"

It turned out that Subaru had decided to replace it with a button and an "automatic" "hill-holder" feature.

Re: Oh Shit, Git

#160

Post by zoomablemind »

motoboi wrote: post #156

> # remove the last commit from the master branch > git reset HEAD~ --hard I see this all the time, this "commits ON a branch" mentality. My secret to understanding git is: branches are just adresses, labels, pointers, aliases to commits. A branch is just a label pointing to a commit. So, you don't "remove (or add) a commit from a branch", you change where a branch point to. Commits are tree nodes, they have a parent…

>...So, you don't "remove (or add) a commit from a branch", you change where a branch point to.

Well, once committed, the corresponding deltas to parent are part of the branch (that is a node of the branch graph). Thus, if user wants to have this commit in a different graph, then the deltas need to be regenerated and recommitted (then deleted from the wrong graph).

As for the branch name, in Git it's just a label for the graph leaf. However, some SCMs maintain branch name for all constituing nodes in the branch graph.

Post reply on HN