Re: [PATCHv4 2/2] pull --rebase: Avoid spurious conflicts and reapplying unnecessary patches
On Thu, Aug 12, 2010 at 10:19 PM, Elijah Newren <newren@gmail.com> wrote:
Show 16 quoted lines
> Hi,
>
> Thanks for the review and comments!
>
> On Thu, Aug 12, 2010 at 7:34 AM, Santi Béjar <santi@agolina.net> 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).
I think this is commit message material.
Show 18 quoted lines
>
>> Subject: Difference between pull --rebase and fetch+rebase
>> Message-ID: <27059158.post@talk.nabble.com>
>> From: martinvz <martin.von.zweigbergk@gmail.com>
>>
>> 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