I have two branches that diverged a long time ago, master and zoo. I work locally and check changes into a remote repository. The remote repository is also set up the same, and the local branches are set up to track the remote branches. Major development has gone on in both sides unfortunately. "master" is the production version. My strategy to get the two together was: 1) Rebase master into zoo. 2) Merge zoo into master. But here is what happens. I spend 3 hours inside "zoo" doing "git rebase master". I go through all the hell of reconciling 6 months of development. Then at the end, it just says that the commits now differ between local "zoo" and "origin/zoo". So I figure, I will pull from "origin/zoo". Naturally, that results in a conflicted merge, which I then clear up. I commit the merge, then push everything back to the remote branch. Now I would guess that my "zoo" branch has everything in it from "master", and it is also in sync with the "origin/zoo" branch. I push and pull and verify that this is so. My thinking is that if I were to attempt a new rebase of master, the beginning of what would be rebased would start from RIGHT NOW, instead of all the commits over the past 6 months. To check this, I type: git rebase master from "zoo". Lo and behold, it starts the whole process over again. I "git rebase --abort", but I am very, very confused. Why does the rebase not remember all the freaking work I just did? Why would I have to rebase the same commits all over again? How do people keep downstream branches up to date if this doesn't work? What am I missing here? I will be extremely grateful for any help and understanding anybody can offer. -- View this message in context: http://www.nabble.com/Git-rebase-aggravation-tp22155203p22155203.html Sent from the git mailing list archive at Nabble.com. -- 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
