ah we love a good rebase
read image description
ALT
1
2
Conversation
Replying to
Best is when there are many commits adding / removing files. Since Git doesn't track renames it has to guess if it was a rename based on file similarity. Sometimes you have particularly cursed commits adding/removing files where cherry picks done later get applied to wrong files.
1
3
End up having this problem all the time with Chromium in particular. They also have these files with a whole bunch of similar extreme nesting in them and when something gets moved too far or was outright removed, Git decides to apply the changes to the completely wrong place.
1
2
Projects with license headers and programming language boilerplate make these problems so much worse because Git thinks any time a small file was deleted and another small file was added, it was a rename. Fairly often just manually redo commits because Git is worse than nothing.
1
1
`git checkout COMMIT directory` where `directory` can be `.` run at the top level directory is particularly helpful to undo whatever nonsense it did and redo it by hand from scratch, then add the changes and continue cherry-pick / rebase. Saves so much time...
2
1
By the way, the best git command ever is git range-diff. You pass 2 ranges of commits and it will compare them as patch sets. It's perfect for verifying your work after rebasing by doing a diff on both ranges of commits to see what you changed with your conflict resolutions.
git range-diff is a major part of maintaining GrapheneOS since every month we rebase onto the new monthly, quarterly or yearly AOSP release. We maintain everything as a clean patch set on top of the latest stable release and we can diff our changes across those versions with it.
1