merge recursive and code movement

There's a use case that merge recursive doesn't seem to handle, and I wonder how difficult it would be to add.

Say you have a merge between OURS and THEIRS, with common ancestor BASE.

Between BASE and THEIRS, a file named header.h has the following changes:

  # Rename header.h to header_new.h
  git mv header.h header_new.h

  # Minor edits to account for the rename such as fixing the
  # include guard:
  perl -pi -e 's/HEADER_H_/HEADER_NEW_H_/' header_new.h

  # Drop a compatibility header.h in place till we can fix all the
  # files which include header.h
  cat > header.h <<-__EOF__
	#ifndef HEADER_H_
	#define HEADER_H_
	#include "header_hew.h"
	#endif // HEADER_H_
  __EOF__

  git add header.h header_new.h
  git commit -m 'rename header.h to header_new.h'

Meanwhile, between BASE and OURS, a few minor changes are made to header.h. This could be as little as a single line change in the middle of the header.h.

Now you merge THEIRS to OURS. Git will just show header.h in conflict. 99% of the time I can do the following:

  git diff MERGE_BASE... header.h | patch header_new.h
  git checkout --theirs header.h
  git add header.h header_new.h

But it would seem like this is something merge recursive should be capable of handling on its own.

j.