{"thread":{"id":"14867","subject":"git blame and cherry-picking","startedAt":"2008-08-06T22:18:33Z","lastAt":"2008-08-07T18:49:29Z","messageCount":7,"participants":["Steven Grimm","Alex Riesen","Avery Pennarun","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"86378","messageId":"91A979F0-1329-4CA6-AADC-6CF55872B57A@midwinter.com","threadId":"14867","inReplyTo":null,"subject":"git blame and cherry-picking","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2008-08-06T22:18:33Z","receivedAt":"2008-08-06T22:18:33Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"What, if any, is the approved way to get git blame to follow cherry- \npicked changes? Right now blame is good about showing you the actual  \nresponsible revision and author in the case of merges, but if you  \ncherry-pick a change with \"-n\" (to test before committing), the  \nmodifications are attributed to the person who did the cherry-pick  \ninstead of the cherry-picked revision's author. Even without the \"-n\"  \noption, the changes are attributed to the cherry-pick *revision*  \ninstead of the original one.\n\nMy horrible hack workaround for now is to temporarily put a grafts  \nentry in place to make git think the cherry-pick revisions I'm  \ninterested in are actually merges. That requires me to know that a  \ngiven revision is a cherry-pick and I have to be careful to remove my  \nfake graft afterwards. What's more, it can result in some strange and  \nseemingly nonsensical \"merge\" topologies if, e.g., a newer change is  \ncherry-picked before an older one.\n\nSurely there must be a better way...?\n\n-Steve\n"},{"id":"86422","messageId":"20080807060940.GA15405@blimp.local","threadId":"14867","inReplyTo":"91A979F0-1329-4CA6-AADC-6CF55872B57A@midwinter.com","subject":"Re: git blame and cherry-picking","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-08-07T06:09:40Z","receivedAt":"2008-08-07T06:09:40Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Steven Grimm, Thu, Aug 07, 2008 00:18:33 +0200:\n> What, if any, is the approved way to get git blame to follow cherry- \n> picked changes?\n\nThe can't be any: cherry-picks are just new commits. You just make the\nsame changes at the new place in the history.\n"},{"id":"86424","messageId":"32541b130808071053g5fd0ce4u24d28263f38e0207@mail.gmail.com","threadId":"14867","inReplyTo":"91A979F0-1329-4CA6-AADC-6CF55872B57A@midwinter.com","subject":"Re: git blame and cherry-picking","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-08-07T17:53:26Z","receivedAt":"2008-08-07T17:53:26Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 8/6/08, Steven Grimm <koreth@midwinter.com> wrote:\n> What, if any, is the approved way to get git blame to follow cherry-picked\n> changes? Right now blame is good about showing you the actual responsible\n> revision and author in the case of merges, but if you cherry-pick a change\n> with \"-n\" (to test before committing), the modifications are attributed to\n> the person who did the cherry-pick instead of the cherry-picked revision's\n> author. Even without the \"-n\" option, the changes are attributed to the\n> cherry-pick *revision* instead of the original one.\n\nIt sounds like you at least want to avoid using \"-n\", if it really\ndoes lose author information that way.  If the patch doesn't work, you\ncan always \"git commit --amend\" or \"git reset --hard HEAD^\".\n\nI don't think tracing through to the original revision is useful\nanyway; nothing you'd find through the original commit would be\nrelevant to git blame, AFAICS, since none of those other patches were\napplied to the branch you're looking at.\n\nHave fun,\n\nAvery\n"},{"id":"86426","messageId":"20080807182256.GF11314@sigill.intra.peff.net","threadId":"14867","inReplyTo":"20080807060940.GA15405@blimp.local","subject":"Re: git blame and cherry-picking","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-07T18:22:56Z","receivedAt":"2008-08-07T18:22:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 07, 2008 at 08:09:40AM +0200, Alex Riesen wrote:\n\n> Steven Grimm, Thu, Aug 07, 2008 00:18:33 +0200:\n> > What, if any, is the approved way to get git blame to follow cherry- \n> > picked changes?\n> \n> The can't be any: cherry-picks are just new commits. You just make the\n> same changes at the new place in the history.\n\nWe used to say \"cherry-picked from...\" in the commit message, but I\ndon't think we do by default any longer. One could follow that link to\nsee the original change (if it still exists!).\n\nYou could potentially have git-blame incorporate that information\n(again, if the referenced commit is even still available), but I'm not\nsure exactly what difference it would make. I don't think you would want\nto start blaming up the original commits line of parentage.\n\n-Peff\n"},{"id":"86427","messageId":"AA6BDC98-8800-4031-8C8F-A4BD326BEC1E@midwinter.com","threadId":"14867","inReplyTo":"20080807182256.GF11314@sigill.intra.peff.net","subject":"Re: git blame and cherry-picking","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2008-08-07T18:37:02Z","receivedAt":"2008-08-07T18:37:02Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"On Aug 7, 2008, at 11:22 AM, Jeff King wrote:\n> You could potentially have git-blame incorporate that information\n> (again, if the referenced commit is even still available), but I'm not\n> sure exactly what difference it would make. I don't think you would  \n> want\n> to start blaming up the original commits line of parentage.\n\nNo, of course not. But one might want to show the original commit's  \nauthor instead of the name of the person who did the cherry pick.  \nThat's mostly what I'm looking for here; knowing where the change  \noriginally came from in terms of the revision graph is occasionally  \ninteresting but not nearly as important.\n\nOne could argue that the real issue here is that while \"git cherry- \npick\" preserves the original author and doesn't have the  \nmisattribution problem, \"git cherry-pick -n\" discards the original  \ncommit's attribution (though it does keep the commit message).  \nObviously git doesn't necessarily know whether the cherry-picker made  \nsubstantial changes before committing and should truly be considered  \nthe author, but one of the use cases for the \"-n\" option is a simple  \n\"make sure you don't commit totally broken revisions\" where there is  \nlittle to no additional editing of the patch and keeping the original  \nauthor would support that use case better.\n\n-Steve\n"},{"id":"86428","messageId":"7vsktgirto.fsf@gitster.siamese.dyndns.org","threadId":"14867","inReplyTo":"AA6BDC98-8800-4031-8C8F-A4BD326BEC1E@midwinter.com","subject":"Re: git blame and cherry-picking","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-07T18:49:07Z","receivedAt":"2008-08-07T18:49:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm <koreth@midwinter.com> writes:\n\n> On Aug 7, 2008, at 11:22 AM, Jeff King wrote:\n>> You could potentially have git-blame incorporate that information\n>> (again, if the referenced commit is even still available), but I'm not\n>> sure exactly what difference it would make. I don't think you would\n>> want\n>> to start blaming up the original commits line of parentage.\n>\n> No, of course not. But one might want to show the original commit's\n> author instead of the name of the person who did the cherry pick.\n\n\"cherry-pick\" lets you say \"-n\" so that you can use the change as if you\nare creating (think of it as a typesaver).  You can ask commit to record\nthe result under the original authorship.\n\nPerhaps a workflow sequence would go like this:\n\n    ... Ah, I like that change by Joe; let's see if that really works ...\n    $ git cherry-pick -n joe/experimental~4\n    $ test test test\n\n    ... Hmm, not quite, let's fix up ...\n    $ edit test edit test\n\n    ... Now it works and I like the result, but I'll edit the comment to\n    ... describe the change I made on top of what he did to make it work.\n    $ git commit -a -c joe/experimental~4\n"},{"id":"86429","messageId":"20080807184929.GA11691@sigill.intra.peff.net","threadId":"14867","inReplyTo":"AA6BDC98-8800-4031-8C8F-A4BD326BEC1E@midwinter.com","subject":"Re: git blame and cherry-picking","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-07T18:49:29Z","receivedAt":"2008-08-07T18:49:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 07, 2008 at 11:37:02AM -0700, Steven Grimm wrote:\n\n> No, of course not. But one might want to show the original commit's  \n> author instead of the name of the person who did the cherry pick. That's \n> mostly what I'm looking for here; knowing where the change originally came \n> from in terms of the revision graph is occasionally interesting but not \n> nearly as important.\n\nOK. I think that is a cherry-pick -n issue, then, as you mention below.\n\n> One could argue that the real issue here is that while \"git cherry-pick\" \n> preserves the original author and doesn't have the misattribution problem, \n> \"git cherry-pick -n\" discards the original commit's attribution (though it \n> does keep the commit message). Obviously git doesn't necessarily know \n> whether the cherry-picker made substantial changes before committing and \n> should truly be considered the author, but one of the use cases for the \n> \"-n\" option is a simple \"make sure you don't commit totally broken \n> revisions\" where there is little to no additional editing of the patch and \n> keeping the original author would support that use case better.\n\nI don't think it would be hard to stuff the cherry-picked commit's info\nsomewhere and to pull it out during git-commit. git-am and git-rebase -i\nare already doing something similar. The harder question is what should\nbe done with multiple \"git cherry-pick -n\" invocations with different\nauthors?\n\nI haven't looked closely at the git-sequencer stuff, but I wonder if\nsome of this will come with it for free. My impression is that the\nprototype is built on _top_ of cherry-pick, but that the C version will\nnot be, and that cherry-pick can then be implemented in terms of the\nsequencer.\n\n-Peff\n"}]}