Something I never quite understood is why, when I rebase on, say, master
and resolve conflicts, and then master
is updated and I go to rebase again on master
, I have to re-resolve all the conflicts I had previously. I know rerere
exists to help with this, but I'm confused on why that has to exist on the first place. I have a question similar to the comment on this original post:
Once you've rebased and resolved the conflicts, surely you are actually changing your commit to a commit premised on the new version of the original. The next time, you shouldn't have to re-resolve this because you're now applying the updated patch?
Shouldn't git
, once I resolve the conflicts at a given pick stage in the rebase, modify the patch so that it's compatible with the new base commit? In other words, I rebase onto master
, resolve all those conflicts. Then master
is updated with a new commit. Say they change a completely unrelated file I didn't touch. I rebase onto that. What's going on step-by-step with git that's causing me to need to re-resolve the conflicts that I had from last time? As I said I would think since rebasing creates new commits that those updated patches would be modified to not conflict with the new base.