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) 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.
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