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
Replying to
yeah, i just end up having the two versions without any of the conflicts side by side because with the conflicts it's unreadable.
1
1
Replying to
git mergetool helps a lot, and despite the name works with rebases / cherry-pick. I use that for 3-way diffs with vimdiff but there are a bunch of other usable tools other than vim.
If Git felt like applying the changes to the wrong files I tend to deal with it by hand though. It's too much trouble to deal with that. I absolutely despise the fact that Git has no way to record renames in commits properly... they could even let you add metadata after the fact.