Re: Wrong conflicts on file splits

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

 



On Mon, May 4, 2009 at 9:27 AM, Michael J Gruber
<git@xxxxxxxxxxxxxxxxxxxx> wrote:
> Jon Smirl venit, vidit, dixit 04.05.2009 14:53:
>> I keep running into this problem, is there anything I can do to make
>> it better? I'm using stgit but this is a problem in git itself.
>>
>> I have a patch that splits file A into two files, A and B.
>> Now I merge with another tree and bring in a one line fix to A.
>> The fix touches the pre-split file A in a section that is going to end up in B.
>> Next I re-apply the patch that splits A into A and B.
>>
>> This results in a large conflict in the post split file A.
>> And no patch being applied to file B which is where the fix belongs.
>>
>> Repeat this process with a multi-line fix and the whole automated
>> merge process breaks down and I have to carefully figure everything
>> out by hand.
>>
>> The merge process seems to be unaware of the newly created file B. No
>> patches or conflict ever end up in it.
>>
>
> Can you provide a test case or at least a list of commands which you are
> issuing? You complain about "merge", but you say you are "applying a
> patch". Are you merging that patch from another branch, or are you
> really applying it as a patch (git-apply/cherry-pick/rebase/what-not)?

What git command does stgit use internally on push/pop?

It's the stg push of a patch creating a split on top of a change to
the section that is going to end up in file B that causes the problem.



>
> Cheers,
> Michael
>



-- 
Jon Smirl
jonsmirl@xxxxxxxxx
--
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]