Conflicts with `git rebase`

So, yesterday I posted a question regarding some weird conflicts when I tried to rebase an upstream branch into my local topic branch.

In the end I used git rebase --merge upstream and solved a lot of conflicts in files I haven't touched since the previous rebase.

My understanding of rebase in such a case is that it detaches my commits from that topic branch, applies the commits from the upstream branch, and then applies (as patches) my commits on top of those. So, it ends up being a fast-forward operation. What I don't understand is... why would I have merge conflicts with those commits that come from upstream. Are those applied as patches as well? I thought is just... the act of "welding" some commits on top of the previous commit that came from the same branch?

I'm asking this because I had a lot of conflicts in files I haven't touched. Oh, and I do daily rebases with this upstream branch.

UPDATE

I've just noticed that some of the commits brought from the upst开发者_如何学Pythonream to my topic branch have their SHA-1 id changed. Does anyone know what could cause Git do to this? Could it be the --merge switch?

My git version is 1.5.6.5

Rebase re-writes history. If you rebase commits that have already been pushed to a remote, you are entering a world of hurt. Even worse if you continue to rebase like this. Rebase has it's avantages at times, but it is a specialty tool IMO, not a casual tool, like merge.

and then applies (as patches) my commits on top of those.

Yes, as new commits

So, it ends up being a fast-forward operation

No. A fast-forward is simply moving the pointer HEAD of that branch. You are introducing new objects from remote and then applying patches on top of that.

If your local and remote were last in sync at A1, and say you added (locally) A2 and A3 commits, and found that the remote had added B1 and B2, rebasing will stash A2 and A3, pull down B1 and B2 (should be a fast-forward since they share a common descendant A1), and then apply patches for A2 and A3 as new commits (hence new SHA-1) A2' and A3'.

So now your local history is: A1 - B1 - B2 - A2' - A3' which is not a fast-forward.