On Sun, Jun 29, 2014 at 4:20 PM, Jason Pyeron <jpye...@pdinc.us> 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.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.
> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to