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

Re: Teach git how to propagate a fix across a file split

From: Björn Steinbrink <hidden>
Date: 2016-06-15 22:47:08

On 2009.07.31 11:19:28 -0400, Jon Smirl wrote:
On Thu, May 14, 2009 at 5:00 PM, Jon Smirl[off-list ref] wrote:
quoted
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.
I just hit this problem again.

It can happen in other forms. In this case I'm trying to rebase three
year old patches forward (good old embedded vendor port and forget
behavior). Part of these patches made a four line change to one file.
About a year latter a 1,000 line section from this file was moved to
another pre-existing file. When I rebase the four line change forward
it generates a merge conflict over the entire 1,000 line section that
was moved. This conflict is in the file the section was moved out of
which is not what you want.

To fix this I have to search for where the 1,000 lines section was
moved to. After I find it I can redo the four line patch.
The search can be done via blame:
git blame -C -C --reverse <old_rev>.. -- <file>

That shows the contents of <file> as of <old_rev> and where those
contents are now (as of HEAD). Of course, if the contents were changed a
lot since they were moved, the results won't be very useful, as git
simply can't find the old code in the new files anymore.

HTH
Björn
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help