On Sun, Jun 29, 2014 at 5:13 PM, Jason Pyeron <jpye...@pdinc.us> wrote: >> -----Original Message----- >> From: Phil Hord >> Sent: Sunday, June 29, 2014 16:27 >> >> 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 > > But I want to avoid thet complicating, while still showing that line 42 was > modified by X. Should this be possible with a merge, without using > cherry-pick?
I think it should. But there are other complications in your project which may be getting in the way. You are merging two branches with no common ancestor. When git walks down either path looking for the source commit for each line, it finds two sources for it. For example, it reaches commit 39ebb06 which appears to be the origin of all lines in that file since it has no parent. I imagine this could act as a short-circuit to further searching. Furthermore, I'm not sure how git should know any better. It seems you already have a merge point for these two branches, but I haven't looked deeply into how that merge was done. But I think the multiple disconnected branch histories may be the cause of the confusion. > Btw I am not able to pull up https://git.wiki.kernel.org/ or > http://git.wiki.kernel.org/ That is strange. It works for me here, and I am just a user like you. Phil -- 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
