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

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

You could abort the rebase, then move back to the commit you want to using the reflog and remove the entries you skipped from the rebase todo.

Would this bring me back to the rebasing process so I don't lose the progress?

Interesting mention of jj, never heard of it before! It says it can use Git as backend, so that means I could do these kinds of operations easily without stringing several commands together on the repositories I'm already working on without changing them?

[–] 2xsaiko@discuss.tchncs.de 2 points 2 days ago (1 children)

Right, you need to first restart the rebase, then git reset --hard to whatever commit from the reflog, then edit the todo list. Might need git rebase --skip too to make it read the next entry. I haven't done this myself yet fwiw.

It says it can use Git as backend, so that means I could do these kinds of operations easily without stringing several commands together on the repositories I’m already working on without changing them?

You can either clone a repo fresh or have it take over an existing git repo that you already have cloned locally. Normally you can only use its own commands, but you can create a repo in colocated mode where you can use both git and jj commands in the same repository, if that's something you or a tool you're using needs.

But in general jj will work with remote git repositories regardless of whether your local checkout is colocated or not, and there's no problem using it side-by-side on the same repo with other people who use git.

I posted an article (not mine) about it here a while ago. https://discuss.tchncs.de/post/26573114

[–] QuazarOmega@lemy.lol 2 points 2 days ago* (last edited 2 days ago) (1 children)

Really cool, I'll give jj a try sometime, thanks for bringing it to my attention!
As for the rebase I'll try in a toy repo, if it works as expected it would be great, this time I ended up aborting and starting over, then doing several rebases on the same range of commits to eventually get to the result I wanted without having to fear losing/breaking something or caving due to the cognitive load of managing many commits at a time

[–] 2xsaiko@discuss.tchncs.de 2 points 2 days ago (1 children)

Another thing about jj which I really love: it makes it a lot more easy to maintain a bunch of PR branches at once. Look at this 8-way-merge here on my fork (2xsaiko): https://github.com/mesonbuild/meson/network. The tip of that is what I'm developing on top of and then squashing changes into one of the commits in one of the branches which are mostly PRs. And rebasing the entire thing on top of upstream's master is essentially trivial, best case it's one command. See https://ofcr.se/jujutsu-merge-workflow for details on how it's done!

[–] QuazarOmega@lemy.lol 2 points 11 hours ago

That looks pretty crazy! I kinda want to unlock this power ngl