Re: Trouble merging renamed but identical files - CONFLICT (rename/rename)

From: Phil Hord <phil.hord@gmail.com>
Date: Jun 29, 2014, 20:26 UTC
Message-ID: <CABURp0q1u_Hzz2ni63oHuinFpBTCzZ+=-6h5YpC0k_bQ_03TSA@mail.gmail.com>
In-Reply-To: <35E240FD8DD74A2F9B80FFCBD818A122@black>

On Sun, Jun 29, 2014 at 4:20 PM, Jason Pyeron <jpyeron@pdinc.us> wrote:

Show 32 quoted lines

>> -----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@gmail.com> wrote:
>> > On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron
>> <jpyeron@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.