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

Git rebase -i is not that scary

cachebag.sh

Post reply on HN
Print view View original

131–140 of 155 posts

Re: Git rebase -i is not that scary

#131

Post by irishcoffee »

xorcist wrote: post #88
irishcoffee wrote: post #18

Earlier quoted context omitted.

The part where git needs to be “understood” is the entire problem. “Do one thing and do it well” was the whole mantra, which was completely ignored with the disaster that is git. It’s objectively awful.

You only have to learn three things to use a computer: Your shell, your editor, and your version control system. That's it. That basic knowledge will carry you far, and will be useful a decade from now. Those are the three best afternoons you can spend. Do it out of respect for the computer.

I am gainfully employed because I’m decent at those 3 things. I’m not sure why you assume I’m not. Fair point though.

Re: Git rebase -i is not that scary

#132

Post by rcxdude »

irishcoffee wrote: post #130
rcxdude wrote: post #62

Earlier quoted context omitted.

Absolutely everything in computing needs to be 'understood' to be used.

Really? How familiar are you with how inodes work on a spinning platter vs an eMMC? Can you speak intelligently about how virtual machines segregate their ram boundaries whilst still maintaining decent performance? What is your familiarity with FIPS? You’re very incorrect.

And you were born with an understanding of how a keyboard and mouse worked or how windows seperated different GUI contexts and what all those symbols around them meant? I'm not saying you have to understand the nuts and bolts because abstractions exist but those abstractions still present you with a model and you need to understand that model to use them. People often present git's model mixed in with its nuts and bolts, which I think is unhelpful because the model is actually really simple and the nuts and bolts are not so important.

Re: Git rebase -i is not that scary

#133

Post by irishcoffee »

rcxdude wrote: post #132
irishcoffee wrote: post #130

Earlier quoted context omitted.

Really? How familiar are you with how inodes work on a spinning platter vs an eMMC? Can you speak intelligently about how virtual machines segregate their ram boundaries whilst still maintaining decent performance? What is your familiarity with FIPS? You’re very incorrect.

And you were born with an understanding of how a keyboard and mouse worked or how windows seperated different GUI contexts and what all those symbols around them meant? I'm not saying you have to understand the nuts and bolts because abstractions exist but those abstractions still present you with a model and you need to understand that model to use them. People often present git's model mixed in with its nuts and bo…

Have you never seen a toddler touch a non-touch screen and be like “wtf?” Or watch a child holding mom’s phone swipe away a text message alert?

Yes, good software is absolutely intuitive. Git is garbage.

Re: Git rebase -i is not that scary

#134

Post by conceptme »

brown9-2 wrote: post #105
xorcist wrote: post #85

Earlier quoted context omitted.

This is a perfect use for tags. They allocate no extra storage space, and act as "savepoints" which you can refer to at any time. (Branches move, tags stay put.) They also guarantee that those loose ends are not garbage collected. Sometimes I delete a bunch of old ones, but any codebase of mine will at any time have a handful of old and probably useless tags. But that's ok.

tags and branches are both just refs to the commit and can be used interchangeably for something like this. tags are not immutable, just in convention.

Annotated tags have their own commit I believe that is ehy you should use annotated tags for release tags.

Re: Git rebase -i is not that scary

#135

Post by chrysoprace »

ablob wrote: post #124
chrysoprace wrote: post #74

Earlier quoted context omitted.

I wonder if it's because it opens in the default visual editor (typically vi/vim) and while I'm primarily a (neo)vim user now, it is certainly not the most intuitive editor to get started with without guidance.

You can always set the editor in your --global or --local config though: git config core.editor "vim" I do agree that using the default editor is a mostly a bad choice due to it being vi/vim rather often.

I know, but as you say that still presents a barrier to entry.

A lot of talented developers that I've worked with use visual git clients exclusively, so imagine their horror when presented not only with an editor they don't use, but also a text-based menu (`git rebase -i`).

Re: Git rebase -i is not that scary

#136

Post by LAC-Tech »

OneDeuxTriSeiGo wrote: post #117
LAC-Tech wrote: post #46

Earlier quoted context omitted.

I still don't know it very well, and it's been well over a decade. I think it's a combination of a few things: - I find it uninteresting. My version control needs are very simple. - Most teams I have been in use a small subset of it. - It's confusing terms and inconsistent cli are huge warning signs to not go down that rabbithole. Today instead of learning Git I read some Tony Hoare, much better. I've been at once pl…

Have you ever read any of the introductory material that the git project itself maintains for teaching how to use the tool? - https://git-scm.com/docs/gittutorial - https://git-scm.com/docs/giteveryday - https://git-scm.com/docs/gitworkflows - https://git-scm.com/docs/gitfaq - https://git-scm.com/cheat-sheet Or if you want to sit down and really learn the nuts and bolts - https://git-scm.com/book/en/v2

Looks like an incredibly dull way to waste hours of my finite life for microscopic benefit.

Re: Git rebase -i is not that scary

#137

Post by selckin »

delusional wrote: post #71
selckin wrote: post #59

Earlier quoted context omitted.

you can just make a backup copy of .git or your entire project dir. When you get lost, just delete your .git, copy from the backup and try again

You never need to do that. git-reflog(1) is the most general solution if you will ever need.

if you're a beginner thats going to be very difficult, restoring the git dir a few times makes the learning process much faster, till it all clicks and you don't need too anymore

Re: Git rebase -i is not that scary

#139

Post by QGQBGdeZREunxLe »

maxloh wrote: post #24

I found the VS Code GitLens extension to be a good abstraction for interactive rebase. It provides a drag-and-drop UI with a dropdown to select actions applied to each commit. That is much easier than editing a text file. Here's a GIF I found with Google: https://yogwang.site/2025/cursor-vscode-gitlens-rebase-edito...

I'm a big fan of https://github.com/MitMaro/git-interactive-rebase-tool on the terminal.

I also use git absorb (https://github.com/tummychow/git-absorb) and lazygit a lot (https://github.com/jesseduffield/lazygit).

Re: Git rebase -i is not that scary

#140

Post by rcxdude »

irishcoffee wrote: post #133
rcxdude wrote: post #132

Earlier quoted context omitted.

And you were born with an understanding of how a keyboard and mouse worked or how windows seperated different GUI contexts and what all those symbols around them meant? I'm not saying you have to understand the nuts and bolts because abstractions exist but those abstractions still present you with a model and you need to understand that model to use them. People often present git's model mixed in with its nuts and bo…

Have you never seen a toddler touch a non-touch screen and be like “wtf?” Or watch a child holding mom’s phone swipe away a text message alert? Yes, good software is absolutely intuitive. Git is garbage.

Because they've already learned a model of how devices with screens work, albeit an imperfect one. Children are pretty good at learning. Software and systems should be easy to learn, but it's not a case of no learning.
Post reply on HN