Hacker News Reader

Comment by nordsieck | Hacker News Reader

One big benefit to fetch+rebase over pull is that you can create a backup branch before you rebase so that if you mess up the rebase too much, you can undo easily.

Another situation I've run into is that sometimes I've made a small change that's stacked on top of a lot of other branches. And if those other branches get squashed and merged, regular rebasing can be really annoying - it is often easier to cherry-pick (I use rebase --onto, but same idea) your changes onto main/master instead.

View on HN

If you mess up a rebase you can always rebase -—abort (/ use the reflog) to restore the pre-rebase state.

> If you mess up a rebase you can always rebase -—abort (/ use the reflog) to restore the pre-rebase state.

That is true. But a few times, I've finished rebasing and regretted how I handled conflicts. And once the rebase is complete, you can't abort any more.

And I haven't put in the time to learn how to use reflog. Maybe this is my sign to do so.

Not much to learn there:

  git reflog <refname>

  git reset --hard <refname>@{1}

Thanks! That's the push I needed.

why create a backup branch instead of just pointing the rebased branch back at the original commit?

> why create a backup branch instead of just pointing the rebased branch back at the original commit?

I mean, isn't that what a backup branch is? How are you going to get the hash of the original commit if you don't create a branch?

I suppose you could use git log or something to print the hash to the terminal, but that's just way more fragile than using git to keep track.

git already keeps track of refs for you.

Reply on news.ycombinator.com