title: Is git pull --rebase safe if you are in a centralized model and never push force?
body: <p>There's a lot of git questions on the safety of rebase and there seems to be consensus that as long as you remember that rewriting public history is rude, you should be safe, i.e. if none of the commits you haven't pushed to the repo from which you are pulling, you are safe.</p>
  
  <p>However there is this one answer that gives me pause:</p>
  
  <p><a href="https://stackoverflow.com/a/2597107/1339987">https://stackoverflow.com/a/2597107/1339987</a></p>
  
  <blockquote>
    <p>Commit to a branch. Push. Merge up to another branch (say you're maintaining two baselines, a patch branch and a new-development branch). Realize other commits have been pushed to the server branch yours is tracking. pull --rebase. Suddenly you've re-made each of the commits against the new hash - and destroyed the merge commit.</p>
  </blockquote>
  
  <p>I tried playing with this but was not able to reproduce the scenario in question (I may need to create a more complicated merge but have failed to do so thus far).  So I am asking for an explanation of this scenario and ideally a set of criteria under which I can safely and relatively mindlessly rely on rebase pulls.</p>