Re: Wrong conflicts on file splits

[Michael J Gruber <git@drmicha.warpmail.net>]

Jon Smirl venit, vidit, dixit 04.05.2009 15:52:
> On Mon, May 4, 2009 at 9:49 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> 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.
> 
> Are there git commands that can do this properly? stgit is just a
> bunch of Python executing git commands, they can change which commands
> are getting called.

OK, I checked the source, and in fact stgit uses git's merge strategies.

I also checked a simple example (splitting `seq 1 20`) in two. It seems
that git's rename detection does not detect that to be a rename/copy
(split). As a consequence, the merge strategy performs only a file based
merge between the versions of A. One would need to teach git about "a
better split detection" in order to cope with such a situation.

On the other hand, if you know the split, can't you redo that manually?
I mean, checkout the new version (with the multi-line fixes), split it,
git-add and git-commit to resolve.

Michael