On 2009.07.31 11:19:28 -0400, Jon Smirl wrote: > On Thu, May 14, 2009 at 5:00 PM, Jon Smirl<jonsmirl@xxxxxxxxx> wrote: > > 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 -- 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