Re: [PATCHv4 2/2] pull --rebase: Avoid spurious conflicts and reapplying unnecessary patches

On Thu, Aug 12, 2010 at 10:19 PM, Elijah Newren [off-list ref] wrote:

Hi,

Thanks for the review and comments!

On Thu, Aug 12, 2010 at 7:34 AM, Santi Béjar [off-list ref] wrote:
<snip>

quoted

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).

I think this is commit message material.

quoted

Subject: Difference between pull --rebase and fetch+rebase
Message-ID: [ref]
From: martinvz <redacted>

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.)

Thanks, you are right.

Santi