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

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Jul 31, 2009, 15:59 UTC
Message-ID: <20090731155937.GA31427@atjola.homenet>
In-Reply-To: <9e4733910907310819x1c6fe089l75ae619b31f9feda@mail.gmail.com>

On 2009.07.31 11:19:28 -0400, Jon Smirl wrote:

Show 25 quoted lines

> On Thu, May 14, 2009 at 5:00 PM, Jon Smirl<jonsmirl@gmail.com> 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