Resolving conflicts during git rebase

Question

For the sake of simplicity, imagine following case:

      D---E---F--- ... ---Z  topic
     /
A---B---C                    master

I'd like to rebase on master, so that the D to Z "chain" is after C , however, all the D , E , F , ..., Z commits creates a conflicts when rebasing them 1 by 1. Let's just say that each of them has a conflict on a different line with commit C .

I'd like to resolve all those conflict at once and not in the rebase interactive mode ( --continue, --abort, --skip ), or what ever it is. My question is whether it's totally bad to ignore the conflicts and do the conflict resolution at the very end. By a new explicit commit or in the last rebase step.

By ingoring I mean: git add -A && git commit

This will lead to the history where some commits contain the code-base in the state that's not working, right?

ps. I don't wan't to be merging, I'd like to rebase.

Answer 1

Yes, it is a bad idea to ignore conflicts reported by Git. The logical change from C to D is not likely to be achieved by the same code change between B and D . If it were simple enough, then Git would not have asked for intervention. If you don't care about history, you could combine all the D to Z commits into one and then try to rebase.

Answer 2

You have the git rerere command for your help.

git rerere

R ecorded R eused R esolution

# enabled the option to record the 
git config --global rerere.enabled true

By the way, if you prefer rerere to auto-stage files it solved (I do), you can ask it to: you just need to tweak your configuration like so:

git config --global rerere.autoupdate true