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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 12, 2010 at 10:19 PM, Elijah Newren <newren@xxxxxxxxx> wrote:
> 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).

I think this is commit message material.

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

Thanks, you are right.

Santi
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]