Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Messing up conflicts during a rebase, thinking I did it right, and then finalizing the rebase and losing work that accidentally disappeared. That's my most common mistake at least.


Find your last entry before the rebase using the reflog and reset your local branch to that entry.

The work isn’t lost, it is sitting right there.


> Find your last entry before the rebase using the reflog and reset your local branch to that entry.

You shouldn’t ever need to go to the reflog unless you’re in an exceptional case, and fit makes it very very easy to get into that exceptional case.


> You shouldn’t ever need to go to the reflog unless you’re in an exceptional case

If "loosing your work and it's not in the git log" isn't an exceptional case, what exactly is a "exceptional case"?


> If "loosing your work and it's not in the git log" isn't an exceptional case, what exactly is a "exceptional case"?

Losing your work should be exceptional. It's very, very easy to fuck a rebase up, and rebasing is (like it or lump it) a common operation. You shouldn't one step away from an exceptional case from a daily operation.


Powerful tools have powerful consequences, case in point: with `rm` you're always one mistake away from blowing away large parts of your work.


this is solved by branching your feature again and rebasing from that or the feature original in case the rebase gets fucked.

you don't have to treat rebases or merges as this black hole of "i have no recourse for not getting it perfect the first time".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: