{"thread":{"id":"39013","subject":"Feature request: implement '--follow' option for `git blame`","startedAt":"2015-04-06T12:12:42Z","lastAt":"2015-04-13T19:07:35Z","messageCount":6,"participants":["KES","Junio C Hamano","Eugen Konkov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"259058","messageId":"4215491428322362@web26m.yandex.ru","threadId":"39013","inReplyTo":null,"subject":"Feature request: implement '--follow' option for `git blame`","fromName":"KES","fromEmail":"kes-kes@yandex.ua","sentAt":"2015-04-06T12:12:42Z","receivedAt":"2015-04-06T12:12:42Z","isPatch":false,"sender":{"key":"kes-kes@yandex.ua","avatar":null},"body":" $ pwd\n /data/mdi2/classes\n\n $ git blame -L22,+1 -- utils.js\n 99b7a802 mdi2/utils.js (user 2015-03-26 21:54:57 +0200 22) #comment\n\n $ git blame -L22,+1 99b7a802^ -- utils.js\n fatal: no such path mdi2/classes/utils.js in 99b7a802^\n\nAs you have noticed, the file were in different directory in that commit\n\n $ git blame -L22,+1 99b7a802^ -- ../utils.js\n c5105267 (user 2007-04-10 08:00:20 +0000 22) #comment 2\n\nDespite on doc\n\n The origin of lines is automatically followed across whole-file renames (currently there is no option to turn\n the rename-following off)\n\nblame does not follow renames. Why?\n\n**UPDATE:** Short answer\n\n`git blame` follow renames but not for `git blame COMMIT^ -- `\n\nBut this is too hard to track file renames manually through bulk of renames and ton of history.\nI think, this behaviour must be fixed to silently follow renames for `git blame COMMIT^ -- `. Or, at least, `--follow` must be implemented, so I can: `git blame --follow COMMIT^ -- `\n\nThe good answer is here:\nhttp://stackoverflow.com/questions/29468273/why-git-blame-does-not-follow-renames\n"},{"id":"259142","messageId":"720501428427590@web5j.yandex.ru","threadId":"39013","inReplyTo":"4215491428322362@web26m.yandex.ru","subject":"Fwd: Feature request: implement '--follow' option for `git blame`","fromName":"KES","fromEmail":"kes-kes@yandex.ua","sentAt":"2015-04-07T17:26:30Z","receivedAt":"2015-04-07T17:26:30Z","isPatch":false,"sender":{"key":"kes-kes@yandex.ua","avatar":null},"body":"\n\n-------- Пересылаемое сообщение --------\n06.04.2015, 15:12, \"KES\" :\n\n    $ pwd\n    /data/mdi2/classes\n\n    $ git blame -L22,+1 -- utils.js\n    99b7a802 mdi2/utils.js (user 2015-03-26 21:54:57 +0200 22)  #comment\n\n    $ git blame -L22,+1 99b7a802^ -- utils.js\n    fatal: no such path mdi2/classes/utils.js in 99b7a802^\n\nAs you have noticed, the file were in different directory in that commit\n\n    $ git blame -L22,+1 99b7a802^ -- ../utils.js\n    c5105267 (user 2007-04-10 08:00:20 +0000 22)    #comment 2\n\nDespite on doc\n\n    The origin of lines is automatically followed across whole-file renames (currently there is no option to turn\n           the rename-following off)\n\nblame does not follow renames. Why?\n\n**UPDATE:** Short answer\n\n`git blame` follow renames but not for `git blame COMMIT^ -- `\n\nBut this is too hard to track file renames manually through bulk of renames and ton of history.\nI think, this behaviour must be fixed to silently follow renames for `git blame COMMIT^ -- `. Or, at least, `--follow` must be implemented, so I can: `git blame --follow COMMIT^ -- `\n\nThe good suggestion is here:\nhttp://stackoverflow.com/questions/29468273/why-git-blame-does-not-follow-renames\n-------- Завершение пересылаемого сообщения --------\n"},{"id":"259162","messageId":"xmqqvbh7baij.fsf@gitster.dls.corp.google.com","threadId":"39013","inReplyTo":"4215491428322362@web26m.yandex.ru","subject":"Re: Feature request: implement '--follow' option for `git blame`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-08T02:48:36Z","receivedAt":"2015-04-08T02:48:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"KES writes:\n\n> **UPDATE:** Short answer\n>\n> `git blame` follow renames but not for `git blame COMMIT^ -- `\n\nSuppose you have file A and file B in your version v1.0.\n\nSix month down the road, the code was much refactored, and you do\nnot need the contents of these two files separately. You have\nremoved A and B and much of what they had is now in file C. That is\nthe current state.\n\n git blame -C HEAD -- C\n\nmay follow the contents from both just fine, but if you _were_\nallowed to say\n\n git blame v1.0 -- C\n\nwhat does it even mean? C did not exist v1.0 at all. Are you\nasking to follow the contents of A back then, or B? How did you\ntell you meant A and not B when you told it C in this command?\n\n\"git blame\" follows content movements, and never treats \"renames\" in\nany special way, as it is a stupid thing to do to think a rename is\nsomehow special ;-)\n\nThe way you tell what content to start digging from to the command\nfrom its command line is to give starting point commit (defaults to\nHEAD but you may give COMMIT^ as your example) and the path in that\nstarting point. As it does not make any sense to tell C to Git and\nthen magically make it guess you meant A in some cases and B in some\nother. If v1.0 did not have C, the only sensible thing to do is to\nexit instead of making a guess (and without telling the user how it\nguessed).\n"},{"id":"259220","messageId":"209433431.20150410094038@yandex.ru","threadId":"39013","inReplyTo":"xmqqvbh7baij.fsf@gitster.dls.corp.google.com","subject":"Re[2]: Feature request: implement '--follow' option for `git blame`","fromName":"Eugen Konkov","fromEmail":"kes-kes@yandex.ru","sentAt":"2015-04-10T06:40:38Z","receivedAt":"2015-04-10T06:40:38Z","isPatch":false,"sender":{"key":"kes-kes@yandex.ru","avatar":null},"body":"Здравствуйте, Junio.\n\nВы писали 8 апреля 2015 г., 5:48:36:\n\nJCH> KES writes:\n\n>> **UPDATE:** Short answer\n\n>> `git blame` follow renames but not for `git blame COMMIT^ -- `\n\nJCH> Suppose you have file A and file B in your version v1.0.\n....\nAs it does not make any sense to tell C to Git and\nJCH> then magically make it guess you meant A in some cases and B in some\nJCH> other. If v1.0 did not have C, the only sensible thing to do is to\nJCH> exit instead of making a guess (and without telling the user how it\nJCH> guessed).\n\nI agree with your complex example. But it will be great to guess in simple case, when in version v1.0 only one file A which were renamed into C half year later.\n\n`git blame COMMIT^ -- C`\n\nFor complex example the clue will be if user supply line number he want to blame. So if user supply line 10 we follow A, if user supply 30 we follow B.\nSimple and great =) (I mean usefull for people)\n\n`git blame --line 10 COMMIT^ -- C` \n`git blame --line 30 COMMIT^ -- C`\n\n\n\n\n\n\n\n-- \nС уважением,\n Eugen mailto:kes-kes@yandex.ru\n"},{"id":"259276","messageId":"xmqqiod04mq6.fsf@gitster.dls.corp.google.com","threadId":"39013","inReplyTo":"209433431.20150410094038@yandex.ru","subject":"Re: Feature request: implement '--follow' option for `git blame`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-13T05:32:33Z","receivedAt":"2015-04-13T05:32:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eugen Konkov writes:\n\n> I agree with your complex example.\n\nNote that it is a norm, not anything complex, that we do not rename\na file wholesale.\n\n> But it will be great to guess in simple case, when in version v1.0\n> only one file A which were renamed into C half year later.\n\nSo you used to have A and somebody renamed that into C in the past.\nThe content of C in the current version is what you used to have in\nA.\n\nWhat should happen if you also have A, whose contents do not have\nany relation to that old A, in today's code?\n\nWhat should happen if you also used to have C, whose contents do not\nhave any relation to that old A or current C?\n\nWhat happens if you added such random guessing and you were not so\nfamiliar with the project history to know these unrelated A's and\nC's that used to exist in the past?\n\nCurrent Git _consistently_ behaves, even in the presense of anything\nthat can lead to confusing behaviour. When you ask\n\n git blame OLD -- A\n\nit does not matter if you have an unrelated A in the revision that\nyou happen to have checked out in your working tree (i.e. HEAD).\nThe above command line talks about the old revision OLD and A talks\nabout the path A in that old revision.\n"},{"id":"259308","messageId":"1962526577.20150413220735@yandex.ru","threadId":"39013","inReplyTo":"xmqqiod04mq6.fsf@gitster.dls.corp.google.com","subject":"Re[2]: Feature request: implement '--follow' option for `git blame`","fromName":"Eugen Konkov","fromEmail":"kes-kes@yandex.ru","sentAt":"2015-04-13T19:07:35Z","receivedAt":"2015-04-13T19:07:35Z","isPatch":false,"sender":{"key":"kes-kes@yandex.ru","avatar":null},"body":"Здравствуйте, Junio.\n\nВы писали 13 апреля 2015 г., 8:32:33:\n\nJCH> Eugen Konkov writes:\n\n>> I agree with your complex example.\n\nJCH> Note that it is a norm, not anything complex, that we do not rename\nJCH> a file wholesale.\n\n>> But it will be great to guess in simple case, when in version v1.0\n>> only one file A which were renamed into C half year later.\n\nJCH> So you used to have A and somebody renamed that into C in the past.\nJCH> The content of C in the current version is what you used to have in\nJCH> A.\n\nJCH> What should happen if you also have A, whose contents do not have\nJCH> any relation to that old A, in today's code?\n\nJCH> What should happen if you also used to have C, whose contents do not\nJCH> have any relation to that old A or current C?\n\nJCH> What happens if you added such random guessing and you were not so\nJCH> familiar with the project history to know these unrelated A's and\nJCH> C's that used to exist in the past?\n\nJCH> Current Git _consistently_ behaves, even in the presense of anything\nJCH> that can lead to confusing behaviour. When you ask\n\nJCH> git blame OLD -- A\n\nJCH> it does not matter if you have an unrelated A in the revision that\nJCH> you happen to have checked out in your working tree (i.e. HEAD).\nJCH> The above command line talks about the old revision OLD and A talks\nJCH> about the path A in that old revision.\n\n\nYes. you are right. I do not think about these examples.\n\n\n-- \nС уважением,\n Eugen mailto:kes-kes@yandex.ru\n"}]}