Hi, Thanks for the review and comments! On Thu, Aug 12, 2010 at 7:34 AM, Santi Béjar <santi@xxxxxxxxxxx> wrote: <snip> > All this makes sense. > > But can you explain when it happens? One possibility is when you don't > fork from the tracking branch as in: That's one possibility. Patch 1/2 in this thread contains testcases for two others. Another possibility is having your patches get upstream by some alternative route (e.g. pulling your changes to a third machine, pushing from there, and then going back to your original machine and trying to pull --rebase). > Subject: Difference between pull --rebase and fetch+rebase > Message-ID: <27059158.post@xxxxxxxxxxxxxxx> > From: martinvz <martin.von.zweigbergk@xxxxxxxxx> > > and this patch should also fix martinvz's issue (I've CC martinvz, can > you test this patch? Thanks). Since you've cc'd martinvz, I'll note for his benefit that in the thread you reference above, you stated, "By the way, when Git tries to apply these two commits it should detect that they are already applied so it should do nothing, isn't it?" The answer is no, it won't detect they are already applied, as explained in the commit message that started the current thread. (If git did detect the changes were already applied, this bug would have been innocuous.) > Can you refer to commits with something like this? > > c85c792 (pull --rebase: be cleverer with rebased upstream branches, 2008-01-26) Sure, I'll start doing that. > You've moved all the lines after the call to "git fetch". It changes > the behavior when the reflog is not enabled, as the old value of > remoteref is lost. Doh. That's what I get for trying to 'clean up' some code and put all the references to setting oldremoteref together. I should have stuck with my original 7-line addition patch. I'll resend the simplified patch. Elijah -- 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