Re: Wrong conflicts on file splits

> Jon Smirl venit, vidit, dixit 04.05.2009 15:42:
>> On Mon, May 4, 2009 at 9:27 AM, Michael J Gruber
>> <git@drmicha.warpmail.net> 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.
>
> I see. So it's really rebasing/applying here rather then merging. I
> don't think they have the necessary info in order to do content-based
> patching across file boundaries.