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

91–100 of 275 posts

Re: Oh Shit, Git?

#91

Post by spokaneplumb »

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 .git dir with an older copy if I screw it up too bad. It's a ton faster than figuring out the right way to un-fuck any particular operation or set of operations.

Re: Oh Shit, Git?

#92

Post by nuancebydefault »

javier_e06 wrote: post #53

Lately I've been asked to avoid merge-commits. They pollute the logs? If my push is blocked I am too far behind I create a new temp branch of master and do a "merge --squash" to it and then a "reset --hard" from temp branch back to my original branch. Heck sometimes I rather keep my changes in patches to void does darn merge CONFLICTS...specially when rebasing.

The thing is if you merge immediately into master and have conflicts, you solve the conflict and only then you can merge. But then the conflict resolution sits at the merge point with a weird default commit message and is hard to decipher.

A nicer way is merge master into your branch, with the rebase option (you can set that option as the default). This will put your changes on top of the master changes that happened during populating your own branch. There you solve any conflicts and those usually immediately show you what happened in the meantime, making it easier to do so. The latest greatest now sits in your branch.

Then as a plus, you can retest that merge and if necessary, fix the merge.

Optionally you can do a pull request for reviewing. The diff the reviewers see is conflict-less and makes sense, has only your changes.

Then simply merge to master, which should be trivial if you don't wait for long.

Re: Oh Shit, Git?

#93

Post by globular-toast »

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.

As a magit user I agree, apart from the fact most GUIs I've seen are horrendously broken and can lead to an even worse mess. For example, I was really confused about how a colleague messing up and got them to show me. Turns out in VS Code if you set the upstream branch correctly (ie. to master), it tries to get you to "sync" the branch. So it assumes the upstream branch is the branch you push to, which makes no sense at all.

Re: Oh Shit, Git?

#94

Post by sampo »

jimbokun wrote: post #61
dmd wrote: post #34

Earlier quoted context omitted.

As everyone knows, though, Git gets easier once you understand branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.

> homeomorphic endofunctors mapping submanifolds of a Hilbert space Has to be easier to understand that then all the arbitrary git commands.

Git commands, while they may be cryptic, actually mean something. Whereas that was just gibberish made by putting random mathematical words together.

(There is a similar sounding joke about category theory, "A monad is just a monoid in the category of endofunctors" but this sentence has a mathematical meaning.)

Re: Oh Shit, Git?

#95

Post by lalaithion »

Certhas wrote: post #57
lalaithion wrote: post #29

Earlier quoted context omitted.

The disconnect between git's beautiful internal model of blobs, a tree of commits, and pointers to commits, and the command line interface is so wild. All of these recipes are unintuitive even if you have a firm grasp of git's model; you also need to know the quirks of the commands! To just look at the first one... wouldn't it be more intuitive for the command line interface to be: # this command exists already; $ gi…

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.

Re: Oh Shit, Git?

#96

Post by koito17 »

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.

Agreed that UIs generally provide a better UX for Git.

I use Magit and doing things like "abort cherry-pick" is discoverable in the interface itself and uses the exact same shortcut as the other "abort X" operations. If I had to use the Git CLI, I'd have no idea where to start.

Similarly, I've made mistakes in interactive rebases where I deleted a commit that shouldn't have been deleted. If I recall correctly, the start of every rebase creates a snapshot that is accessible from the reflog, so this is a safe way to revert changes from a rebase gone wrong. Magit's UI for the reflog is exactly the same as the UI for the log, so I was not lost when I saw it for the first time. With the Git CLI, I'd likely have no clue what's going on.

Re: Oh Shit, Git?

#97

Post by jimbob45 »

phtrivier wrote: post #89

This will feel very weird in April 2025, when we celebrate the 20th anniversary of git. I was there. And at some point I wondered if I should learn git, darcs, or bazaar, to replace SVN or CVS. Or did I try mercurial too ? I wonder if the "GitHub" effect has basically killed the need for a newcomer in the space of VCS. Maybe at some point, the yak is shaved enough ?

SVN has always worked for me. You don’t have to “teach” people SVN because it’s intuitive and works just fine for the 99% case. I wish we would all stop larping as 1337 hackerz and just admit that git is overkill for the vast majority of people.

Re: Oh Shit, Git?

#98

Post by lalaithion »

neild wrote: post #35
lalaithion wrote: post #29

Earlier quoted context omitted.

The disconnect between git's beautiful internal model of blobs, a tree of commits, and pointers to commits, and the command line interface is so wild. All of these recipes are unintuitive even if you have a firm grasp of git's model; you also need to know the quirks of the commands! To just look at the first one... wouldn't it be more intuitive for the command line interface to be: # this command exists already; $ gi…

The "move a branch from one commit to another without changing anything" command is "git reset". "git reset --hard" is "...and also change all the files in the working directory to match the new branch commit". "git reset --soft" is "...but leave the working directory alone".

git reset only works if you're on the branch you want to move, which is why every one of these example flows has you create your new branch, then do the reset, then switch to the new branch, instead of just allowing you to move a branch you're not on.

Re: Oh Shit, Git?

#99

Post by globular-toast »

reaperducer wrote: post #78
philipwhiuk wrote: post #74

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

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 the previous options were crap. Perhaps Mercurial is better, but git is good enough.

Re: Oh Shit, Git?

#100

Post by JTyQZSnP3cQGa8B »

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 agree, I have used git for more than 10 years and it's the only tool that I refuse to learn. The command-line interface is cryptic and infuriating. I'd rather write assembly language again than learn what is essentially a CLI to the internals of git. It's not high-level, it's not intuitive, and it can be destructive if you don't use the right option. I stick to GUIs and simple actions, and I never had any problems compared to all the horror stories of my CLI-loving coworkers.
Post reply on HN