{"thread":{"id":"2137","subject":"git-diff-tree rename detection for single file","startedAt":"2005-10-18T19:56:06Z","lastAt":"2005-10-19T16:04:42Z","messageCount":6,"participants":["David Ho","Junio C Hamano","Linus Torvalds","Nicolas Pitre"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"10217","messageId":"4dd15d180510181256i1c5a82d9ld62acaedb493cf71@mail.gmail.com","threadId":"2137","inReplyTo":null,"subject":"git-diff-tree rename detection for single file","fromName":"David Ho","fromEmail":"davidkwho@gmail.com","sentAt":"2005-10-18T19:56:06Z","receivedAt":"2005-10-18T19:56:06Z","isPatch":false,"sender":{"key":"davidkwho@gmail.com","avatar":"https://gravatar.com/avatar/1596ca9708bdd00a5c237f15af1011d65b6ef49a3bd9e9152e0bf09e7577fb5a?d=mp&s=160"},"body":"Hi,\n\nI have a small suggestion to make the diff of a renamed file a bit\nmore meaningful.  I have a file that is renamed-edited and commited. \ngit-diff-tree -M -p <commit> shows one result and git-diff-tree -M -p\n<commit> <filename> shows another.  If they both show a rename\noccurred then I think the single file git-diff-tree will be more\nuseful.\n\nAny strange idea I have is to make git-diff-tree traverse the list of\ncommits (assuming the list is returned from git-rev-list) to trace\nrenames of the file to its origin.  Of course I don't know how useful\nthis is to most.\n\nDavid\n\n[davidho@penguin git-tutorial]$ git-diff-tree -r -M -p \\\n8c77fe87790276b4e0b2650d7c5799eb893ac3ed\n8c77fe87790276b4e0b2650d7c5799eb893ac3ed\ndiff --git a/goodbye b/ciao\nsimilarity index 83%\nrename from goodbye\nrename to ciao\nindex 0561cce..d8259f5 100644\n--- a/goodbye\n+++ b/ciao\n@@ -4,3 +4,4 @@ Play, play, play\n Work, work, work\n Eat, eat, eat\n Drink, drink, drink\n+Chew, chew, chew\n\n\n[davidho@penguin git-tutorial]$ git-diff-tree -r -M -p \\\n8c77fe87790276b4e0b2650d7c5799eb893ac3ed ciao\n8c77fe87790276b4e0b2650d7c5799eb893ac3ed\ndiff --git a/ciao b/ciao\nnew file mode 100644\nindex 0000000..d8259f5\n--- /dev/null\n+++ b/ciao\n@@ -0,0 +1,7 @@\n+Hello World\n+It's a new day for git\n+Play, play, play\n+Work, work, work\n+Eat, eat, eat\n+Drink, drink, drink\n+Chew, chew, chew\n"},{"id":"10224","messageId":"7vu0fepn0x.fsf@assigned-by-dhcp.cox.net","threadId":"2137","inReplyTo":"4dd15d180510181256i1c5a82d9ld62acaedb493cf71@mail.gmail.com","subject":"Re: git-diff-tree rename detection for single file","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-18T20:50:54Z","receivedAt":"2005-10-18T20:50:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Ho <davidkwho@gmail.com> writes:\n\n> I have a small suggestion to make the diff of a renamed file a bit\n> more meaningful.  I have a file that is renamed-edited and commited. \n> git-diff-tree -M -p <commit> shows one result and git-diff-tree -M -p\n> <commit> <filename> shows another.  If they both show a rename\n> occurred then I think the single file git-diff-tree will be more\n> useful.\n\nSorry, this has vetoed by Linus long time ago.  The <filename>\nrestricts the paths being passed to the diff machinery upfront,\nso once you say <filename>, the rename detection will see only\nthat path and nothing else to compare and guess which other file\nthat file in question is a copy of.\n"},{"id":"10251","messageId":"7virvujkcw.fsf@assigned-by-dhcp.cox.net","threadId":"2137","inReplyTo":"7vu0fepn0x.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-diff-tree rename detection for single file","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-19T02:45:03Z","receivedAt":"2005-10-19T02:45:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> David Ho <davidkwho@gmail.com> writes:\n>\n>> I have a small suggestion to make the diff of a renamed file a bit\n>> more meaningful.  I have a file that is renamed-edited and commited. \n>> git-diff-tree -M -p <commit> shows one result and git-diff-tree -M -p\n>> <commit> <filename> shows another.  If they both show a rename\n>> occurred then I think the single file git-diff-tree will be more\n>> useful.\n>\n> Sorry, this was vetoed by Linus long time ago.  The <filename>\n> restricts the paths being passed to the diff machinery upfront,\n> so once you say <filename>, the rename detection will see only\n> that path and nothing else to compare and guess which other file\n> that file in question is a copy of.\n\nHaving said that, I think we *could* introduce a new flag to\ngit-diff-* brothers, --late-pathspec, that makes them apply the\npaths restriction on the output side instead.  For obvious\nreasons, using this flag would not make any sense unless you are\nusing one of -M, -C, or --pickaxe-all.\n\nA related thing I have long longed for is a rename following\n\"git-diff-tree --stdin\".\n\n    git-rev-list HEAD | git-diff-tree --stdin -M git-commit.sh\n\nThis command line, as everybody hopefully knows, is how \"git\nwhatchanged\" is implemented internally.  If git-diff-tree were\ntaught to follow the rename history, when it hits the boundary\nthat git-commit-script was renamed to git-commit.sh, it could\nstart acting as if the pathspec given were git-commit-script\nfrom that point.  To see that rename it needs --late-pathspec;\nthe current pathspec filters the input so the above command line\nwould not even care what git-commit-script looked like when the\nrename happend.  It would just tell git-commit.sh appeared from\nnowhere.\n\nIf implemented naively, this rename-following would have funny\ninteractions when it hits a merge commit, so it may probably be\nharder than it sounds, but this would be a good way to do\nannotate as well.\n"},{"id":"10253","messageId":"Pine.LNX.4.64.0510182004100.3369@g5.osdl.org","threadId":"2137","inReplyTo":"7virvujkcw.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-diff-tree rename detection for single file","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-19T03:12:43Z","receivedAt":"2005-10-19T03:12:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 18 Oct 2005, Junio C Hamano wrote:\n> \n> Having said that, I think we *could* introduce a new flag to\n> git-diff-* brothers, --late-pathspec\n\nGaah. Why? It's really not possible to do it efficiently inside \ngit-diff-xyz, so whatever implementation would basically boil down to \nsomething you can already do with some trivial scripting, basically \nboiling down to:\n\n\tgit-diff-tree -r -M | grep pathnamelist | git-diff-helper\n\nNow, several reasons why it's much better to do this kind of \n\"--late-pathspec\" at a higher level (instead of inside the git-diff-xyz \nfamily):\n\n (a) git-diff-xyz is already some of the more complex core parts. It's not \n     likely a good idea to make them any more complex, unless there's some \n     very fundamental reason for it.\n\n (b) without pathname limits, git-diff-tree is very slow. Well, it's \n     actually very fast compared to something braindead like CVS, but if \n     you want to track a single file over a thousand releases, it's MUCH \n     MUCH faster to do the pathname limit at the beginning. Otherwise \n     you'll spend all your time reading and comparing big trees with tens \n     of thousands of entries.\n\n (c) with a higher-level thing, what you can do is have a TWO-phase thing: \n     use the fast pathname limiter in git-diff-tree to figure out when \n     that file changes in history, and then _only_ for those commits do \n     you go back and then do the much more expensive \"git-diff-tree -r -M\" \n     followed by the pathname-limiting post-processing.\n\nSee what I'm saying? You really can do the post-processing outside of \ngit-diff-tree, and you will in fact be much better off if you do so.\n\nThe performance impact of pruning the pathnames _before_ diffing them was \nabsolutely staggering. You couldn't reasonably do a \"git-whatchanged -p\" \non the kernel for a single file if you didn't do it the way we do it now.\n\n\t\t\tLinus\n"},{"id":"10256","messageId":"7virvuhylm.fsf@assigned-by-dhcp.cox.net","threadId":"2137","inReplyTo":"Pine.LNX.4.64.0510182004100.3369@g5.osdl.org","subject":"Re: git-diff-tree rename detection for single file","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-19T05:20:21Z","receivedAt":"2005-10-19T05:20:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> See what I'm saying?\n> ...\n> The performance impact of pruning the pathnames _before_ diffing them was \n> absolutely staggering. You couldn't reasonably do a \"git-whatchanged -p\" \n\nYes, I understood and agreed to that logic on May 27th.  That's\nwhy the message you are responding said we could add a new flag,\nto give the choice to the user to accept full-tree scan.\n\nThe \"diff-tree --stdin that follows rename history\" example\nmight want to have some change in either the core side of diff,\nor in the rev-list.  It may help to have both.  I still haven't\nthought through the issues.\n\nBTW, I really liked your example that piped multiple diff-trees\ntogether.  That is a neat trick.\n"},{"id":"10285","messageId":"Pine.LNX.4.64.0510191203220.5288@localhost.localdomain","threadId":"2137","inReplyTo":"7virvuhylm.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-diff-tree rename detection for single file","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2005-10-19T16:04:42Z","receivedAt":"2005-10-19T16:04:42Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 18 Oct 2005, Junio C Hamano wrote:\n\n> BTW, I really liked your example that piped multiple diff-trees\n> together.  That is a neat trick.\n\nYeah.  Those should really be picked up to augment the documentation \nsection.\n\n\nNicolas\n"}]}