Jon Smirl venit, vidit, dixit 04.05.2009 15:52: > On Mon, May 4, 2009 at 9:49 AM, Michael J Gruber > <git@xxxxxxxxxxxxxxxxxxxx> wrote: >> Jon Smirl venit, vidit, dixit 04.05.2009 15:42: >>> 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. >> >> 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 -- 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