On Sun, Jun 29, 2014 at 11:31 AM, Phil Hord <phil.h...@gmail.com> wrote: > On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron <jpye...@pdinc.us> wrote: >> Sorry for the http://pastebin.com/1R68v6jt (changes the merge to >> 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually reconciles the merge), >> but it was too long to be readable in the email.
Ok, I think I understand the issue you are trying to solve now. Git (rather famously[1]) does not record renames or copies. It is expected instead that renames and copies will be detected when it is important after the fact. This allows us to ignore rename detection and resolution when creating project history; in the future, better rename/copy detection will "just work" on existing repositories and the repos themselves will not need to be adjusted. What you are encountering now seems to be a shortcoming of Git's current rename/copy detection. But you are trying to overcome today's shortcoming by adjusting your project history to accommodate it. Instead you should just do the merge like you normally would without regard to how 'git blame' shows the result. Maybe there is a bug here still, but it is probably in git-blame. [1] https://git.wiki.kernel.org/index.php/GitFaq#Why_does_Git_not_.22track.22_renames.3F -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
