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

  • footfaults@lemmygrad.ml
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    11 hours ago

    If you are continually rebasing and having to fix the same merge conflict over and over, you should look at https://git-scm.com/book/en/v2/Git-Tools-Rerere

    You can also do a git rebase -i and mark a commit as edit and git will stop at that commit in the rebase to allow you to stop, look around, and make changes… I think that is what you are looking for

    • QuazarOmega@lemy.lolOP
      link
      fedilink
      arrow-up
      1
      ·
      10 hours ago

      Not exactly, because n commits will have been squashed into one, so making the edit would lose the reference to the originals which should have been squashed with other commits, visually maybe this helps:

      A (pick) -> B (squash) -> C (squash) -> D (pick)
      

      When it should have been:

      A (pick) -> B (squash) -> D (pick) -> C (squash)
      

      I had just created A+B+C, then realised C should have been out

      • footfaults@lemmygrad.ml
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        4 hours ago

        Not exactly, because n commits will have been squashed into one, so making the edit would lose the reference to the originals which should have been squashed with other commits

        See but you can break the commit back apart by doing a git rebase interactive, selecting that squashed commit as the commit to edit, then doing a git reset HEAD~1 then recommit it in pieces, then git rebase --continue

        Then git rebase -i a second time and then remove the commit that you don’t want to be included