On Sun, 11 May 2008, Steve French wrote: > > That is not what I meant. I meant that since May 6th I only did one > - and those messages still showed up. So I just ran a git-rebase > origin which removed them You're doing something wrong then, and your rebased result is suspect. Have you done a "git fetch" to fetch what is in my current tree? Because if you haven't, then you're generating the "this is the new state" without actually taking into account that the old state was already pulled! And that *old* state contains those four merges that I got from your previous pull request! So now you likely rebased the commits that I already merged (again, because you *think* they are just local to your branch, because you haven't updated your origin reference point), and they are now duplicates of something I already have (but with different commit ID's, since your rebase has moved them around in the history). So now, if I were to pull again, I'd just get the same commits all over again, just as duplicates (plus any new ones, of course). Git would probably merge it all fine - unless your new ones were to the same area as the old ons, in which case it might be unhappy about the fact that both branches changed things in the same area - but the history would be crud. In other words: you *must*not* rebase stuff that you have already publicized. That just creates problems. The good news is that you can most likely fix it all up by just doing git fetch git rebase origin because now the *new* rebase will try to rebase it all over again, but now it will see that I already merged the old ones, so the rebase will just skip those commits, and you should have only the *real* new ones pending again. Linus -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
