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
@QuazarOmega I always do
git branch tmpbefore doing a rebase, to have a backup. Also useful for checking nothing got lost in conflict resolution. #gitThat’s not what I need, I can just abort the rebase in this case and I’d get back my branch as it was before I started, but I explicitly want to go to a state in the middle so not as to lose the modifications that I did intend to do.
Aside from that, I also do that, have seen what hell can be like in rebasing, so knowing where you started is always valuable, I agree
That’s maybe something I think is sus. If it’s at all possible, make a before-rebase branch, and make a small change in a rebase, check that the results are the same, then do another. I wrote git-test specifically for this work flow. (it runs tests, but only if the tree is one or hasn’t seen before)
https://github.com/spotify/git-test
My issue wasn’t so much if it managed to run and more of “I don’t want this change to have happened here” kind of thing, still that’s a neat tool! I wish I could use it, but the codebase I’m working on is in such a hugely sorry state, no testing suite set up is the last of the many problems that most likely won’t be solved because they’re not “important enough”, not like features (built with cardboard and duct tape), yeah we can’t allocate much time at all to code quality and general work for the project infrastructure if we can call it that.
About the generic advice of making smaller rebases one by one, yes, I’ll learn to do that, I also solved it like that in the end
@QuazarOmega I don’t know for sure, sorry. Like someone said on that link, the reflog should have a record, but you’ll need to either abort the rebase and then pick out the right commit, or forcibly kill git’s tracking of the rebase operation. When I know a rebase is going to be long and complicated, I’ll break it down into multiple rebases.
Yeah I think that’s the bigger takeaway from the discussion here, I’ll keep that to heart.
Sorry, what comment are you referring to?