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