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

111–120 of 275 posts

Re: Oh Shit, Git?

#111

Post by adamc »

globular-toast wrote: post #99
reaperducer wrote: post #78

Earlier quoted context omitted.

Git is a technology that was invented to simplify things that ended up getting so complex over time that an entire industry started up around it to try to make it simple again. See also: Docker. Probably lots of others.

Actually, no. Git was a technology invented specifically to enable Linux kernel development. It hasn't become any more complex since its inception. The problem is most people aren't doing kernel development and have absolutely no idea what a distributed version control system is, yet they use git, a distributed version control system. I have no idea why we use it, to be honest, but I'm very glad that we do because th…

We were using svn before Git and easy cloning (and then PRs) has solved a LOT of problems. There are definitely still some things left to improve, though.

Re: Oh Shit, Git?

#112

Post by jeppester »

philipwhiuk wrote: post #74

My hot take is that Git isn't nearly as hard as the endless blogs pretend.

I'm happy I didn't have to scroll too far to see this.

Git's CLI isn't elegant, but it really isn't that big of a deal if you understand the basics of what a commit is, what a branch is etc.

I struggle to understand why so many devs decide to treat it like mysterious arcane sorcery instead of just spending the needed time on learning how it works.

The same can be said about regexes.

Regexes and git are probably the two tools which I have benefitted the most from learning compared to how little time I've spend on learning them - and I wouldn't even consider myself an expert on either.

Re: Oh Shit, Git?

#113

Post by spokaneplumb »

leptons wrote: post #30
jazzyjackson wrote: post #23

Earlier quoted context omitted.

I guess we're coming from different places. In my vernacular, ending a comment with "...really?" is about as casual as calling somebody bro. It's gender neutral btw.

"Bro" is the furthest thing from "gender neutral". Not sure how you could think it's gender neutral. It originated from male behavior and is definitely not gender neutral. You can address women as "bro" and they might even respond to you but they'll think you're absolutely weird.

I'm about 95% sure that if I ask my two school-age daughters if it's weird to address girls and women as "bro" or "bruh" in informal circumstances, they'll say no. Since I hear them do it with some regularity.

Re: Oh Shit, Git?

#114

Post by MrJohz »

SebastianKra wrote: post #46

We should start recommending UIs as the default way to learn Git. It would solve a third of these problems and another third wouldn't even come up. If you later decide that the CLI is faster, go ahead. But first, people need to see visually how they can interact with the tree. I like fork.dev, but most clients are pretty similar at this point.

I've started recommending jj as a (git compatible) alternative to git, and one of the things I like about it is that the default action if you run `jj` with no arguments shows the relevant parts of the commit tree and where you are in it. This is a great reorientation tool, because you can see at a glance which commit you're working on right now, the branches and history associated with it, any other active branches in your repository, and for each you can see whether each commit had messages, changes associated with it, etc.

It's really powerful because it gives you precisely that visual layout that shows you what's going on in the repository, and what you're doing right now.

Re: Oh Shit, Git?

#115

Post by fragmede »

lalaithion wrote: post #95
Certhas wrote: post #57

Earlier quoted context omitted.

The real "internal model" of git contains much more data/moving parts. There isn't one tree of commits, there are typically at least two: local and remote Branches are not just pointers to commits, but also possibly related to pointers in the other tree via tracking. Stash and index and the actual contents of the working directory are additional data that live outside the tree of commits. When op says "avoid git rese…

None of these seem to preclude a command to make an arbitrary branch point to an arbitrary commit without changing anything else.

This works if the branch exists or creates it if it doesn't exist, but not if it's checked out.

    git branch -f branch_name commit
if it's checked out:

    git reset --hard commit

Re: Oh Shit, Git?

#117

Post by julienb_sea »

Oh shit, I accidentally `git reset HEAD~1` and moved the last commit to file diffs, which was a merge to master, and my file diff now is both the last branch merge and everything I've done in the last 8hrs. I did this once and it was a gigantic PITA to undo, if anyone has any hot tips for that particular idiocy...

Re: Oh Shit, Git?

#118

Post by jaapz »

pitaj wrote: post #3

Some changes I would make: 1. Always use `git switch` instead of `git checkout` 2. Avoid `reset --hard` at all costs. So for the "accidentally committed something to master that should have been on a brand new branch" issue, I would do this instead: # create a new branch from the current state of master git branch some-new-branch-name # switch to the previous commit git switch -d HEAD~ # overwrite master branch to th…

Could you motivate why you suggest these? Why is `switch` better than `checkout`? And why not use `reset --hard`?

Re: Oh Shit, Git?

#119

Post by marssaxman »

SebastianKra wrote: post #46

We should start recommending UIs as the default way to learn Git. It would solve a third of these problems and another third wouldn't even come up. If you later decide that the CLI is faster, go ahead. But first, people need to see visually how they can interact with the tree. I like fork.dev, but most clients are pretty similar at this point.

I have not used such a tool in a long time, and never with git: but my past experience with GUI frontends for version control was that they work fine when everything is working fine, but once you have a mess to clean up, nobody can help you.

It has generally worked better for me to use the same interface everyone else is using, even when that interface is awful, because that eases communication with the rest of the team. It also lets me take advantage of online troubleshooting resources, which all assume you are doing things the normal way.

Re: Oh Shit, Git?

#120

Post by fragmede »

spokaneplumb wrote: post #91
frakt0x90 wrote: post #73

I'm not proud of it, but my #1 "Oh shit" git operation is to just delete my local repo, reclone, and reapply the changes. Works really well for me 95% of the time. The rest I ask dev ops guy to help.

I've been using Git for almost 15 years, and have twice built programs/products that use Git internally to achieve certain results (that is, the program/product itself uses Git for things, not just using Git to manage the source code for the program/product) and... sometimes before doing something a little gnarly in Git I'll still just do "cp -R .git ../git-backup" or something like that, so I can replace my entire .…

Reflog is your friend.

    git break-my-shit
    git reflog
        ... output saying where you were before things broke
        ... grab the good commit sha
    git reset --hard good_commit_sha_from_reflog
Post reply on HN