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

41–50 of 155 posts

Re: Git rebase -i is not that scary

#41

Post by bob1029 »

Rebase is scary if you are conflicting on many items.

I have a simple rule where if the rebase cannot be solved within a few commit rewrites that I will restart the branch from latest master.

If you are suffering from really difficult rebase scenarios, it's likely that the senior developers are more at fault than the junior developers. The way you organize work over the codebase has the biggest impact on how things would conflict. If nothing ever does, rebasing is a trivial operation.

Re: Git rebase -i is not that scary

#42

Post by xelxebar »

hetman wrote: post #31
flyingcircus3 wrote: post #9

After more than a decade of using git, I know that my comfort with rebase, and confidence that I wont make an error I can't undo, comes from knowing that I can always abort. And assuming it wasn't garbage collected, I can always get back to orphaned commits, or the commit before I rebased, as long as I keep their hashes. I can definitely look back on my less confident days as times when I wrongly assumed I was walkin…

You don't need to keep their hashes because git keeps them for you. If you realise too late that things went terribly wrong, you can get the pre-rebase hashes with "git reflog". (It can take a little getting used to knowing how to identify them quickly after a rebase but they're there.)

Better yet, git reset ORIG_HEAD or whatever is usually sufficient[0]. The reflog is the general solution, but git's magic references do provide quite a few niceties.

https://www.man7.org/linux/man-pages/man7/gitrevisions.7.htm...

Re: Git rebase -i is not that scary

#44

Post by LAC-Tech »

irishcoffee wrote: post #18
nixpulvis wrote: post #7

I feel like if you're scared of rebasing, you don't actually understand git.

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.

yeah I would really love to see a subset of git with a sane cli. would switch in a heartbeat.

Re: Git rebase -i is not that scary

#45

Post by noam_k »

vivzkestrel wrote: post #36

- i often go back like 5 commits and make changes like this - git rebase -i ^ - select edit - git reset --soft HEAD~ - make some changes - git add . && git commit -m "changes" - git rebase --continue - Am I using git rebase wrong?

I wouldn't say it's wrong.

My preference, however, is creating a fixup commit and using rebase to squash it into the old one.

Edit: A sibling comment mentioned "git history fixup" which I'll have to try out.

Re: Git rebase -i is not that scary

#46

Post by LAC-Tech »

teaearlgraycold wrote: post #37
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.

It could be so much better. At the same time, it’s one of the core tools for a developer. You’ll learn it eventually. You’re going to be using version control for decades. I’ve met devs many years into their careers who don’t understand rebase. It’s like going to a metal shop and they’re complaining about the learning curve on their welder and half the tradesmen are still at a novice level.

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 place where they rebased, and it was awful. Complete waste of time. (great place otherwise though)

Re: Git rebase -i is not that scary

#47

Post by rdevilla »

teaearlgraycold wrote: post #37
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.

It could be so much better. At the same time, it’s one of the core tools for a developer. You’ll learn it eventually. You’re going to be using version control for decades. I’ve met devs many years into their careers who don’t understand rebase. It’s like going to a metal shop and they’re complaining about the learning curve on their welder and half the tradesmen are still at a novice level.

[dead]

Re: Git rebase -i is not that scary

#48

Post by conradludgate »

I should publish it at some point (it's just a simple bash script), but I made a convenient alias `git bisect-rebase` which helps catch up very old branches.

It isn't particularly fast, but it uses bisect to find the first commit on the target branch that conflicts with your branch, then let's you rebase to that commit. You then repeat the process until you are caught up.

The idea is that solving one conflict many times is usually quite easy, especially if you know the conflicting commit messages, but solving many conflicts in one go is not so easy. This was inspired by me rebasing a 6 month old branch which refactored a file that happened to have many edits in between.

Re: Git rebase -i is not that scary

#49

Post by auscompgeek »

conradludgate wrote: post #48

I should publish it at some point (it's just a simple bash script), but I made a convenient alias `git bisect-rebase` which helps catch up very old branches. It isn't particularly fast, but it uses bisect to find the first commit on the target branch that conflicts with your branch, then let's you rebase to that commit. You then repeat the process until you are caught up. The idea is that solving one conflict many ti…

That somewhat sounds like the sort of thing git imerge does.

Re: Git rebase -i is not that scary

#50

Post by mikemcquaid »

I’ve used Git for 20 years now and wrote a book about it.

The biggest mistake most sources make when teaching about history rewriting is omitting these two lessons first:

- it’s easy to lose uncommitted data in Git and hard to lose committed data

- given this, learn how to use ‘git reflog’ to see what you’ve done and how to undo/redo it (as this post recommends but, even then, a little too late)

If you just get in the habit of constant committing and checking reflog: you’ll never lose data.

(Related lesson from my 10 years employed by GitHub: they almost never do the git gc you’d expect to remove commits so once you push a commit: it’s likely there forever and identifiable by that same hash from anywhere in the fork network. This can be bad/scary so be aware).

Post reply on HN