{"thread":{"id":"13987","subject":"using git-blame with patches as input","startedAt":"2008-06-16T21:35:17Z","lastAt":"2008-06-17T14:17:58Z","messageCount":6,"participants":["Don Zickus","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"80075","messageId":"20080616213517.GE20727@redhat.com","threadId":"13987","inReplyTo":null,"subject":"using git-blame with patches as input","fromName":"Don Zickus","fromEmail":"dzickus@redhat.com","sentAt":"2008-06-16T21:35:17Z","receivedAt":"2008-06-16T21:35:17Z","isPatch":false,"sender":{"key":"dzickus@redhat.com","avatar":null},"body":"I deal with a lot of backported patches that are a combination of multiple\ncommits. I was looking to develop a tool that would help me determine\nwhich chunks of the patch are upstream (not necessarily currently in HEAD\nbut at some point in the file's history).\n\nFor example, if I took the top three commits from HEAD and appended them\ninto one patch file and then ran this tool with the patch as input, I\nwould hope that it gave as output the three original commits.\n\ngit-blame seem to handle a lot of the pieces I would need but my little\nbrain can't follow all the logic behind some of the mechanisms.\n\nSeeing that git-blame can take patch chunks and traverse through commit\nhistory to see if a particular chunk can be blamed on a parent, I feel\nlike I am most of the way there. Unfortunately, I don't quite understand\nsome of the algorithms git-blame does when it splits the patch chunks into\nsmaller pieces to determine which pieces are blame-able on the parents.\n\nIs there anyone who can help explain some of the low level logic to me?\n\nWhat I would like to do is take a patch as input, split it into chunks and\ntraverse through the commit history looking for a match (or something of\nhigh similarity) and output that commit id for each patch chunk.\n\ngit-cherry does something close but patches have to be exact whereas my\nsituation has a combination of patches. I also understand there are\nplenty of normal scenerios where my approach falls flat on its face (but I\nhave ideas for those). I just wanted to get a simple common case going\nfirst.\n\nThanks in advance.\n\nCheers,\nDon\n"},{"id":"80077","messageId":"7vej6x9hpk.fsf@gitster.siamese.dyndns.org","threadId":"13987","inReplyTo":"20080616213517.GE20727@redhat.com","subject":"Re: using git-blame with patches as input","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-16T21:45:59Z","receivedAt":"2008-06-16T21:45:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Don Zickus writes:\n\n> I deal with a lot of backported patches that are a combination of multiple\n> commits. I was looking to develop a tool that would help me determine\n> which chunks of the patch are upstream (not necessarily currently in HEAD\n> but at some point in the file's history).\n>\n> For example, if I took the top three commits from HEAD and appended them\n> into one patch file and then ran this tool with the patch as input, I\n> would hope that it gave as output the three original commits.\n\nA quick and dirty hack would be to:\n\n\trm .git/index\n\tsed -ne 's/^[+ ]//p' -e '/^@@/p' patches... >file\n git add file\n git commit -m 'only \"a file\" remains'\n git blame -C -C -w file\n\nwhich would try blaming all the postimage concatenated together ;-)\n"},{"id":"80078","messageId":"7vabhl9hap.fsf@gitster.siamese.dyndns.org","threadId":"13987","inReplyTo":"20080616213517.GE20727@redhat.com","subject":"Re: using git-blame with patches as input","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-16T21:54:54Z","receivedAt":"2008-06-16T21:54:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Don Zickus writes:\n\n> For example, if I took the top three commits from HEAD and appended them\n> into one patch file and then ran this tool with the patch as input, I\n> would hope that it gave as output the three original commits.\n\nUnfortunately blame does not work in such an inefficient way. The patch\ntext from your second commit (that is, the diff that shows what used to be\nin the first commit and what is in the second commit) may be further\nrewritten in the third commit, so if you start blaming such a text from\nHEAD, the blame stops at the HEAD commit saying \"the text you have is even\nnewer\".\n\n> ... Unfortunately, I don't quite understand\n> some of the algorithms git-blame does when it splits the patch chunks into\n> smaller pieces to determine which pieces are blame-able on the parents.\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/28826\n"},{"id":"80080","messageId":"7v4p7t9gov.fsf@gitster.siamese.dyndns.org","threadId":"13987","inReplyTo":"7vabhl9hap.fsf@gitster.siamese.dyndns.org","subject":"Re: using git-blame with patches as input","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-16T22:08:00Z","receivedAt":"2008-06-16T22:08:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Don Zickus writes:\n> ...\n>> ... Unfortunately, I don't quite understand\n>> some of the algorithms git-blame does when it splits the patch chunks into\n>> smaller pieces to determine which pieces are blame-able on the parents.\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/28826\n\nIn the article quoted, \"blame\" refers to a very old \"git-blame\" code that\ndoes not in our codebase anymore. It talks about \"git-pickaxe\" which\nlater took over the \"git-blame\" name, which happend in acca687\n(git-pickaxe: retire pickaxe, 2006-11-08).\n\nIt talks about \"NEEDSWORK\" to hint that the implementation was incomplete,\nrefering to the version that eventually lead to cee7f24 (git-pickaxe:\nblame rewritten., 2006-10-19).\n"},{"id":"80141","messageId":"20080617141519.GK16941@redhat.com","threadId":"13987","inReplyTo":"7vej6x9hpk.fsf@gitster.siamese.dyndns.org","subject":"Re: using git-blame with patches as input","fromName":"Don Zickus","fromEmail":"dzickus@redhat.com","sentAt":"2008-06-17T14:15:19Z","receivedAt":"2008-06-17T14:15:19Z","isPatch":false,"sender":{"key":"dzickus@redhat.com","avatar":null},"body":"On Mon, Jun 16, 2008 at 02:45:59PM -0700, Junio C Hamano wrote:\n> Don Zickus writes:\n> \n> > I deal with a lot of backported patches that are a combination of multiple\n> > commits. I was looking to develop a tool that would help me determine\n> > which chunks of the patch are upstream (not necessarily currently in HEAD\n> > but at some point in the file's history).\n> >\n> > For example, if I took the top three commits from HEAD and appended them\n> > into one patch file and then ran this tool with the patch as input, I\n> > would hope that it gave as output the three original commits.\n> \n> A quick and dirty hack would be to:\n> \n> \trm .git/index\n> \tsed -ne 's/^[+ ]//p' -e '/^@@/p' patches... >file\n> git add file\n> git commit -m 'only \"a file\" remains'\n> git blame -C -C -w file\n> \n> which would try blaming all the postimage concatenated together ;-)\n\nHeh. Interesting. I'll try that today. Thanks.\n\nCheers,\nDon\n"},{"id":"80142","messageId":"20080617141758.GL16941@redhat.com","threadId":"13987","inReplyTo":"7vabhl9hap.fsf@gitster.siamese.dyndns.org","subject":"Re: using git-blame with patches as input","fromName":"Don Zickus","fromEmail":"dzickus@redhat.com","sentAt":"2008-06-17T14:17:58Z","receivedAt":"2008-06-17T14:17:58Z","isPatch":false,"sender":{"key":"dzickus@redhat.com","avatar":null},"body":"On Mon, Jun 16, 2008 at 02:54:54PM -0700, Junio C Hamano wrote:\n> Don Zickus writes:\n> \n> > For example, if I took the top three commits from HEAD and appended them\n> > into one patch file and then ran this tool with the patch as input, I\n> > would hope that it gave as output the three original commits.\n> \n> Unfortunately blame does not work in such an inefficient way. The patch\n> text from your second commit (that is, the diff that shows what used to be\n> in the first commit and what is in the second commit) may be further\n> rewritten in the third commit, so if you start blaming such a text from\n> HEAD, the blame stops at the HEAD commit saying \"the text you have is even\n> newer\".\n\nI know, but I am trying to crawl before I run. So I am attacking the\nsimple cases first to help me understand how the whole git internal\nmechanisms work (I am still trying to figure out the correct way to walk\nthe revision list for a particular file using git-blame as a guide). Once\nmy code works for the simple cases, then I can attack the more 'normal'\ncases like you described above.\n\nCheers,\nDon\n"}]}