Thread (4 messages) flat view 4 messages, 2 authors, 2016-06-15

Teach git how to propagate a fix across a file split

From: Jon Smirl <hidden>
Date: 2016-06-15 22:46:46

Are there any git merge experts looking for something to do? We just
hit this situation again merging some ALSA branches for 2.6.31.

A basic problem description:
Pending change for 2.6.31 splits file A into A and B
Fix is added to 2.6.30 in file A
The fix in A is in a section that is going to be in file B for 2.6.31

Merge the two branches and note that git totally messes up on the
merge. It can't figure out that the fix needs to go into file B.

On Mon, May 4, 2009 at 10:54 AM, Michael J Gruber
[off-list ref] wrote:
Jon Smirl venit, vidit, dixit 04.05.2009 15:52:
quoted
On Mon, May 4, 2009 at 9:49 AM, Michael J Gruber
[off-list ref] wrote:
quoted
Jon Smirl venit, vidit, dixit 04.05.2009 15:42:
quoted
On Mon, May 4, 2009 at 9:27 AM, Michael J Gruber
[off-list ref] wrote:
quoted
Jon Smirl venit, vidit, dixit 04.05.2009 14:53:
quoted
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


-- 
Jon Smirl
jonsmirl@gmail.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help