2

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.

WestCoastProjects
  • 58,982
  • 91
  • 316
  • 560
  • As VonC notes in his (edited) answer, pull runs `git merge` rather than `git rebase`. If there are N commits to rebase, a rebase has the same amount of "pain" involved as running N separate merges, while a merge runs just *one* merge. So merge is, in a way, fundamentally simpler. Rebase is often better, but not always better. You can tell `git pull` to run `git rebase`, but I suggest avoiding `git pull` entirely: use `git fetch`, then *choose* merge vs rebase, based on what you have vs what you just got by fetching. – torek Jul 27 '17 at 14:36
  • @torek In this case the `merge` is clearly what I wanted: when actually is `rebase` working better? Feel free to add another answer. – WestCoastProjects Jul 27 '17 at 14:54
  • Rebase isn't *better*, nor is it *worse*. It's just *different*. See, e.g., the related question https://stackoverflow.com/q/45345564/1256452 (rebasing multiple branches) and the lower part of my answer, which is more about "why choose merge or rebase". – torek Jul 27 '17 at 15:13
  • @torek: To clarify: I did not say "merge is better *always*": I said *in this case*. Will look at your other answer – WestCoastProjects Jul 27 '17 at 15:46

1 Answers1

3

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)
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250