14
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 07 Mar 2025
14 points (93.8% liked)
Programming
18728 readers
558 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
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
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 asedit
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 forNot 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:
When it should have been:
I had just created A+B+C, then realised C should have been out
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, thengit rebase --continue
Then
git rebase -i
a second time and then remove the commit that you don't want to be includedI 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