Programming

426 readers

12 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

Is there a way to rewind the git rebase state? (lemy.lol)

submitted 2 days ago* (last edited 2 days ago) by QuazarOmega@lemy.lol to c/programming@programming.dev

16 comments fedilink hide all child comments

Hi, I've got myself stuck on an issue, I've started a big rebase (I know that was already a bad idea to begin with, but, just in case, the information I'm looking for could always come in handy in other occasions), I reordered a few commits and squashed some, while in the process I resolved a few conflicts, then after I resolved one of them and got to the next conflict I realised that I shouldn't have put a certain commit there, is there a way to rewind the process to the previous step while staying in the rebase? That way I could move the commit to where it should be and continue.
I know you can edit the todo (git --edit-todo), but that only works for the next commits, I also can't just reset back by the number of commits I want, e.g. git reset --hard HEAD~4, because for the rebase those commits remain as done and doing git rebase --continue only brings me to where I am already, the next conflict to resolve.
So I wonder, is there a way to move out commits of the done list back into todo? Also for example if I trashed an unmerged file completely while messing around, so I can get it back to its initial state, this would be extremely useful

you are viewing a single comment's thread
view the rest of the comments

[–] MajorHavoc@programming.dev 9 points 2 days ago* (last edited 2 days ago) (1 children)

Whatever you do, familiarize yourself with git reflog. It contains all the commits, regardless of your current branch state. Even ones you might think you lost. (For about two weeks until it cleans itself up.)

In your shoes, I usually abort the rebase and start a new branch and cherry-pick the commits I need.

It takes awhile, but it's reliable.

Source: In my overconfidence, I screw up my local git state pretty often.

[–] QuazarOmega@lemy.lol 2 points 12 hours ago (1 children)

How does cherry picking improve the workflow? I'm not sure I understand, is it so you can keep the original branch as reference and know where you could have screwed up if it happens?

[–] MajorHavoc@programming.dev 1 points 8 hours ago

is there a way to move commit out of the way Todo later?

This is what cherry-pick does for me. Now that the work is all done, I can cherry-pick the commits into the new branch in any order I find convenient (and often in an order that causes fewer git conflicts, or no git conflicts to resolve.)

Note that this approach is much stronger if the original commits are fairly focused and purposeful.

In extreme cases, I stop and rebase the new or old branch to clean up the commits before I cherry-pick them onto the same branch.

In essence, all of these techniques are just ways for me to very slowly and methodically organize thoughts, using git.

Also, sometimes it's all too messy and I just copy and paste all the change I need into a fresh clean branch.