title: Git: Can there be merge conflicts on a file that was never modified in the merge source?
body: <p><strong>TL;DR</strong> : From a purely theoretical perspective, is it possible for Git to report conflicts on a file during the <em>merging</em> (not rebasing) of a branch into master if that file has never been modified at all on the branch (which was created directly from master) ?</p>
  
  <p>When I merge my dev branches back into master, I am often presented with conflicts on files that for the life of me I cannot remember to have ever modified - or even opened. So I am trying to understand if - given how Git works, which I don't know well enough - this is actually possible in specific circumstances, or if instead this is impossible so I should focus on something apparently modifying some files in my working tree without me noticing (f.ex. something like Save Actions in Eclipse, automatic formatting, line ending handling etc.).</p>
  
  <p>I am only talking about file conflicts, not tree conflicts nor anything else that might involve file deletions or renamings or movings.</p>
  
  <p>Here is an example of my very simple typical workflow, using EGit with Eclipse (always up to date):</p>
  
  <p><strong>1</strong>) I create a dev branch from master; I tick the "Configure upstream for push and pull" checkbox, and in the "When pulling" listbox I select "Merge" (the other entries are "Rebase", "Rebase preserving merge commits", "Rebase interactively").</p>
  
  <p><strong>Nobody else will be committing to that branch, local and remote, <em>at all</em>.</strong> Only me and only from one computer.</p>
  
  <p><strong>2</strong>) I checkout that dev branch and for some days I commit my changes to it everyday. Every single commit is done using "Commit and Push" instead of just "Commit", because I want all my commits to always be on the remote branch too.</p>
  
  <p>On some occasions the Push part of my "Commit and Push" results in a "Rejected - Not fast-forward". In those cases doing a "Pull" and then repeating the Push solves, and some colleagues say that it's normal to have to do a Pull first to avoid that the Push results in "Not fast-forward". This is not the problem though.</p>
  
  <p><strong>3</strong>) The time comes to merge my dev branch back into master. I pull, switch back to master, pull, select Merge, choose my local dev branch, under "Merge options" I select "Squash", under "Fast forward options" I leave the default "If a fast-forward, only update the branch pointer" (the other options are "If a fast-forward, create a merge commit" and "If not a fast-forward, fail").</p>
  
  <p>Then I click Merge and I get "Result: conflicting", I go to solve those conflicts and in some cases neither the conflicting code shown in red under "Mine" (master) nor the corresponding code shown in red under "Theirs" (my dev branch) is something I wrote. I never modified that file in any part, ever, and yet it has conflicting changes when merging this branch - on which this file has never been changed - into master.</p>
  
  <p>So my question is, from a purely theoretical perspective, do possible situations exist where Git is supposed to report conflicts on a file during the merging of a branch into master although that file has never been modified at all on the branch ? And if yes, does my workflow described above qualify as one of such situations ?</p>
  
  <p>It's not a duplicate of <a href="https://stackoverflow.com/q/41064345/2814308">this</a> because that's about using rebase.</p>