On Sun, Jun 29, 2014 at 4:20 PM, Jason Pyeron <jpyeron@xxxxxxxx> wrote: >> -----Original Message----- >> From: Phil Hord >> Sent: Sunday, June 29, 2014 16:09 >> >> On Sun, Jun 29, 2014 at 11:31 AM, Phil Hord >> <phil.hord@xxxxxxxxx> wrote: >> > On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron >> <jpyeron@xxxxxxxx> 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. > > Looking at http://pastebin.com/1R68v6jt , I have a work around. > > In summary, 7.git cherry-pick -x HEAD..rebranding , then > > git merge $(echo 'Merge of 1ca13ed2271d60ba93d40bcc8db17ced8545f172 branch - > rebranding' |\ > git commit-tree -p HEAD -p rebranding \ > $(git cat-file -p HEAD | grep ^tree | sed -e 's/^tree //') ) > > Now it is perfect in the blame and log --graph. Yes, but your workaround unnecessarily duplicates commits and complicates the history of your project. You are munging your project to compensate for git's current shortcomings. But it's your project. Your choice. -- 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