Git rebase causing merge conflicts on essentially all files - even untouched ones

Question

The typical behavior of git rebase is a relatively "clean" merge from the base to the local.

Occasionally however things go south. Basically every file that has been touched in the base requires manual merging into the local - regardless of whether the files had even been touched/changed locally

Why would this happen? Is there a reasonable workaround?

Update

For some reason in this scenario

git pull

worked just fine. It required manual merging of one file - and that was a valid manual merge.

So I guess this question has in a sense devolved into "what are the conditions that a git pull were required as opposed to git rebase. I will look for applicable Q&A.

Answer 1

One possible reason is the eol (end of line) characters, which might be different between the two branches.

Quit first tour current rebase (since Git 2.12: git rebase --quit)

Try again your rebase with the option (merge strategy) -X ignore-space-at-eol, to see if the issue persists.

---

git pull works just fine

That is the difference between pull (fetch + merge) and rebase (replay commits)

 x--x--x--x--X     (master)
        \
         --o--o--O (origin/master)

A pull will merge two HEAD commits X and O who might differ only in one file.

 x--x--x--x--X-----M     (master after git pull)
        \         /
         --o--o--O (origin/master)

A rebase (or git pull --rebase) would replay master on top of origin/master, and previous 'x' commits might introduce a lot of conflict, even if X (HEAD) only differ from one file from origin/master HEAD O.

 x--x--x
        \         
         --o--o--O--x'--X' (master)
           (origin/master)