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
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
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
I know, but that feels really clunky to me, like an unclean solution, I know that commit will disappear regardless, but I don't like room for more human error like that by manually re-editing
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.
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?
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.
I see, now that makes sense to me as well! I too make commits messily as thoughts crop up, so I think this technique might be good for me in some cases, thanks!
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.
I also recommend checking out jj (https://github.com/jj-vcs/jj), it makes big rebases a lot more pleasant because of its conflict model and because you can always undo operations like this.
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?
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
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
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!
That looks pretty crazy! I kinda want to unlock this power ngl
If I'm understanding you correctly, you can create a branch to mark where you are git branch tmp then abort the rebase. Switch to tmp get the history like you wanted, then switch back. Finally do a git rebase -i again, but immediately git reset --hard tmp. Now you have the resolved commits you want, and can delete any you don't want to do again with git --edit-todo.
Maybe.
Hmm, that sounds like it could be what I'm looking for, had never consider you could branch while in the middle of a rebase, nice!
Pretty sure you have to abort and start over.
@QuazarOmega I always do git branch tmp before doing a rebase, to have a backup. Also useful for checking nothing got lost in conflict resolution. #git
That'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 not what I need
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)
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.
You can always make patchfiles and apply those.
Instead of rebasing, consider a new brach and then cherry picking commits.
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 wormhole through a path of communities !webdev@programming.dev
