{"thread":{"id":"20401","subject":"blame on a deleted/renamed file","startedAt":"2009-08-05T12:16:13Z","lastAt":"2009-08-05T17:25:53Z","messageCount":8,"participants":["Dan McGee","Björn Steinbrink","Matthieu Moy","Thomas Rast","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"119609","messageId":"449c10960908050516k25ef0a92sd8616de29a93ea5f@mail.gmail.com","threadId":"20401","inReplyTo":null,"subject":"blame on a deleted/renamed file","fromName":"Dan McGee","fromEmail":"dpmcgee@gmail.com","sentAt":"2009-08-05T12:16:13Z","receivedAt":"2009-08-05T12:16:13Z","isPatch":false,"sender":{"key":"dpmcgee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/265817?v=4"},"body":"Is there no easy way in git to get a blame on a file that has either\nbeen renamed or deleted? I'll step through my thought process, and a\nquick google and read of the manpage returned nothing obvious. Here is\nthe repository in question if it matters:\ngit://projects.archlinux.org/pacman.git. I located a particular commit\nI was interested using a plain git-blame:\n$ git blame scripts/makepkg.sh.in\n\nOK, looks like lines moved around enough that we got stuck here, let's\nsee what this patch did:\n$ git show e19d7da4\n\nOK, it did a move of a bunch of lines into functions that GIT couldn't\nquite track:\n$ git annotate --follow \"scripts/makepkg.in\" e19d7da4~1\nfatal: cannot stat path 'scripts/makepkg.in': No such file or directory\n\n$ git annotate --follow \"scripts/makepkg.sh.in\" e19d7da4~1\nfatal: no such path scripts/makepkg.sh.in in e19d7da4~1\n\nHelp? Or do I need to think about writing some sort of patch for it?\nThis is the first thing I have seen svn be able to do[1] that git\ncan't. :)\n\n-Dan\n\n[1] svn annotate http://path/to/repo/path/to/file@2345\n"},{"id":"119610","messageId":"20090805123754.GA13340@atjola.homenet","threadId":"20401","inReplyTo":"449c10960908050516k25ef0a92sd8616de29a93ea5f@mail.gmail.com","subject":"Re: blame on a deleted/renamed file","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-08-05T12:37:54Z","receivedAt":"2009-08-05T12:37:54Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.08.05 07:16:13 -0500, Dan McGee wrote:\n> Is there no easy way in git to get a blame on a file that has either\n> been renamed or deleted? I'll step through my thought process, and a\n> quick google and read of the manpage returned nothing obvious. Here is\n> the repository in question if it matters:\n> git://projects.archlinux.org/pacman.git. I located a particular commit\n> I was interested using a plain git-blame:\n> $ git blame scripts/makepkg.sh.in\n> \n> OK, looks like lines moved around enough that we got stuck here, let's\n\nHow did it get stuck? The output I see follows the changes the whole way\nback through scripts/makepkg.in, scripts/makepkg.in and scripts/makepkg.\n\n> see what this patch did:\n> $ git show e19d7da4\n> \n> OK, it did a move of a bunch of lines into functions that GIT couldn't\n> quite track:\n> $ git annotate --follow \"scripts/makepkg.in\" e19d7da4~1\n> fatal: cannot stat path 'scripts/makepkg.in': No such file or directory\n\nWhere does that --follow come from? I don't see that in the man page.\n\nAnd scripts/makepkg.in got added in e19d7da4, so its parent didn't have\nit.\n\n> $ git annotate --follow \"scripts/makepkg.sh.in\" e19d7da4~1\n> fatal: no such path scripts/makepkg.sh.in in e19d7da4~1\n\nSame deal, scripts/makepkg.sh.in didn't exist in e19d7da4~1 either, it\ngot renamed from scripts/makepkg.in in b5f8a44be\n\n> Help? Or do I need to think about writing some sort of patch for it?\n> This is the first thing I have seen svn be able to do[1] that git\n> can't. :)\n\nUhm, no, svn fails in the exact same way, not quite unexpected.\n\ndoener@atjola:~ $ mkdir h\ndoener@atjola:~ $ cd h\ndoener@atjola:h $ svnadmin create repo\ndoener@atjola:h $ svn co file://$PWD/repo wc\nChecked out revision 0.\ndoener@atjola:h $ cd wc\n\ndoener@atjola:wc $ touch foo; svn add foo; svn commit -m init\nA foo\nAdding foo\nTransmitting file data .\nCommitted revision 1.\ndoener@atjola:wc $ svn mv foo bar; svn commit -m rename\nA bar\nD foo\nAdding bar\nDeleting foo\n\nCommitted revision 2.\ndoener@atjola:wc $ cd ..\n\ndoener@atjola:h $ svn blame file://$PWD/repo/bar\ndoener@atjola:h $ svn blame file://$PWD/repo/bar@1\nsvn: '/bar' is not a file in revision 1\n\nBjörn\n"},{"id":"119611","messageId":"vpqr5vqbevk.fsf@bauges.imag.fr","threadId":"20401","inReplyTo":"20090805123754.GA13340@atjola.homenet","subject":"Re: blame on a deleted/renamed file","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-08-05T12:54:07Z","receivedAt":"2009-08-05T12:54:07Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Björn Steinbrink writes:\n\n> doener@atjola:h $ svn blame file://$PWD/repo/bar\n> doener@atjola:h $ svn blame file://$PWD/repo/bar@1\n> svn: '/bar' is not a file in revision 1\n\nbut \"svn blame bar -r 1\" here actually means \"give me the blame for\nthe file whose name is now 'bar' starting from revision 1\". I don't\nknow how to do such thing with a single git command.\n\n-- \nMatthieu\n"},{"id":"119615","messageId":"200908051524.46502.trast@student.ethz.ch","threadId":"20401","inReplyTo":"449c10960908050516k25ef0a92sd8616de29a93ea5f@mail.gmail.com","subject":"Re: blame on a deleted/renamed file","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-08-05T13:24:43Z","receivedAt":"2009-08-05T13:24:43Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Dan McGee wrote:\n> \n> This is the first thing I have seen svn be able to do[1] that git\n> can't. :)\n> \n> [1] svn annotate http://path/to/repo/path/to/file@2345\n\nThe only thing broken is git-annotate's guessing code to see if you\nuse the 'git annotate ' (legacy) or 'git annotate\n ' syntax.\n\nI'd simply write the unambiguous\n\n git blame e19d7da4~1 -- \"scripts/makepkg.in\"\n\nand similarly for other revisions. And you'll immediately notice that\ngit *can* do this.\n\n> OK, it did a move of a bunch of lines into functions that GIT couldn't\n> quite track:\n\nYou can try\n\n git blame -C -C scripts/makepkg.sh.in\n\nto let git try *really* hard to find out where the lines come from.\nNote that it does find some lines from older commits, e.g.,\n\n 2ef1c841 scripts/makepkg.in (Dag Odenhall 2007-05-30 23:04:36 +0200 470)\n\nin the body of download_sources, which was moved (but apparently not\nchanged) in e19d7da4 (Andrew Fyfe, 2007-06-01 22:10:27 +0100).\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"119616","messageId":"449c10960908050654v3823da76p1ddb5a2bbb5c323d@mail.gmail.com","threadId":"20401","inReplyTo":"20090805123754.GA13340@atjola.homenet","subject":"Re: blame on a deleted/renamed file","fromName":"Dan McGee","fromEmail":"dpmcgee@gmail.com","sentAt":"2009-08-05T13:54:09Z","receivedAt":"2009-08-05T13:54:09Z","isPatch":false,"sender":{"key":"dpmcgee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/265817?v=4"},"body":"2009/8/5 Björn Steinbrink :\n> On 2009.08.05 07:16:13 -0500, Dan McGee wrote:\n>> Is there no easy way in git to get a blame on a file that has either\n>> been renamed or deleted? I'll step through my thought process, and a\n>> quick google and read of the manpage returned nothing obvious. Here is\n>> the repository in question if it matters:\n>> git://projects.archlinux.org/pacman.git. I located a particular commit\n>> I was interested using a plain git-blame:\n>> $ git blame scripts/makepkg.sh.in\n>>\n>> OK, looks like lines moved around enough that we got stuck here, let's\n>\n> How did it get stuck? The output I see follows the changes the whole way\n> back through scripts/makepkg.in, scripts/makepkg.in and scripts/makepkg.\n\nI said nothing about it not following renames. I asked about it\nfollowing *those lines*. I know it already made the jump from\nscripts/makepkg.sh.in to scripts/makepkg.in, sorry if I wasn't clear\nthere.\n\n>> see what this patch did:\n>> $ git show e19d7da4\n>>\n>> OK, it did a move of a bunch of lines into functions that GIT couldn't\n>> quite track:\n>> $ git annotate --follow \"scripts/makepkg.in\" e19d7da4~1\n>> fatal: cannot stat path 'scripts/makepkg.in': No such file or directory\n>\n> Where does that --follow come from? I don't see that in the man page.\n\nIt's not. The git-annotate manpage is misleading as heck though; I see\nnow I should have went straight to git-blame instead. Why have the two\ncommands diverged so much?\n\nThomas Rast had it perfect when suggesting this, which works perfectly\n(for what I wanted):\n$ git blame e19d7~1 -- scripts/makepkg.in\n\n> And scripts/makepkg.in got added in e19d7da4, so its parent didn't have\n> it.\n\nNot sure where you are seeing that, it was changed in that revision,\nnot added...\n\n>> $ git annotate --follow \"scripts/makepkg.sh.in\" e19d7da4~1\n>> fatal: no such path scripts/makepkg.sh.in in e19d7da4~1\n>\n> Same deal, scripts/makepkg.sh.in didn't exist in e19d7da4~1 either, it\n> got renamed from scripts/makepkg.in in b5f8a44be\n\nThat was my whole point here- I was stabbing in the dark so I showed\nyou everything I tried because the git-annotate manpage failed me.\n\n>> Help? Or do I need to think about writing some sort of patch for it?\n>> This is the first thing I have seen svn be able to do[1] that git\n>> can't. :)\n>\n> Uhm, no, svn fails in the exact same way, not quite unexpected.\n>\n> doener@atjola:~ $ mkdir h\n> doener@atjola:~ $ cd h\n> doener@atjola:h $ svnadmin create repo\n> doener@atjola:h $ svn co file://$PWD/repo wc\n> Checked out revision 0.\n> doener@atjola:h $ cd wc\n>\n> doener@atjola:wc $ touch foo; svn add foo; svn commit -m init\n> A         foo\n> Adding         foo\n> Transmitting file data .\n> Committed revision 1.\n> doener@atjola:wc $ svn mv foo bar; svn commit -m rename\n> A         bar\n> D         foo\n> Adding         bar\n> Deleting       foo\n>\n> Committed revision 2.\n> doener@atjola:wc $ cd ..\n>\n> doener@atjola:h $ svn blame file://$PWD/repo/bar\n> doener@atjola:h $ svn blame file://$PWD/repo/bar@1\n> svn: '/bar' is not a file in revision 1\n\nsvn blame file://$PWD/repo/foo@1 works perfectly though, that was my use case.\n\nSorry for doing like a point-by-point refute of your response here, I\nprobably wasn't clear enough in my original email. However, thank you\nThomas Rast for your suggestions, as the git-blame syntax is much more\npowerful and allows me to do exactly what I wanted.\n\nDoes anyone object to making the following wording in the git-annotate manpage:\nThe only difference between this command and linkgit:git-blame[1] is that\nthey use slightly different output formats, and this command exists only\nfor backward compatibility to support existing scripts, and provide a more\nfamiliar command name for people coming from other SCM systems.\n\nslightly stronger? git-blame destroys git-annotate as far as I can see\nwith the \"rev first then file\" syntax which actually allows you to get\npast annotations on renamed or deleted files.\n\n-Dan\n"},{"id":"119618","messageId":"20090805140941.GB13340@atjola.homenet","threadId":"20401","inReplyTo":"449c10960908050654v3823da76p1ddb5a2bbb5c323d@mail.gmail.com","subject":"Re: blame on a deleted/renamed file","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-08-05T14:09:41Z","receivedAt":"2009-08-05T14:09:41Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.08.05 08:54:09 -0500, Dan McGee wrote:\n> 2009/8/5 Björn Steinbrink :\n> > On 2009.08.05 07:16:13 -0500, Dan McGee wrote:\n> >> Is there no easy way in git to get a blame on a file that has either\n> >> been renamed or deleted? I'll step through my thought process, and a\n> >> quick google and read of the manpage returned nothing obvious. Here is\n> >> the repository in question if it matters:\n> >> git://projects.archlinux.org/pacman.git. I located a particular commit\n> >> I was interested using a plain git-blame:\n> >> $ git blame scripts/makepkg.sh.in\n> >>\n> >> OK, looks like lines moved around enough that we got stuck here, let's\n> >\n> > How did it get stuck? The output I see follows the changes the whole way\n> > back through scripts/makepkg.in, scripts/makepkg.in and scripts/makepkg.\n> \n> I said nothing about it not following renames. I asked about it\n> following *those lines*. I know it already made the jump from\n> scripts/makepkg.sh.in to scripts/makepkg.in, sorry if I wasn't clear\n> there.\n\nHm, I still don't see what you mean. For some lines it stopped at\ne19d7da4, yeah, but those were new lines, added in that commit, at least\nthose that I checked (e.g. \"local ct=0\" in generate_checksums()). For\nthe others, it already went back further.\n\n> > And scripts/makepkg.in got added in e19d7da4, so its parent didn't have\n> > it.\n> \n> Not sure where you are seeing that, it was changed in that revision,\n> not added...\n\nNo idea, I guess I got confused by the various makepkg.* versions :-/\nEspecially by the \"stab in the dark\" blame call. ;-)\n\n> >> $ git annotate --follow \"scripts/makepkg.sh.in\" e19d7da4~1\n> >> fatal: no such path scripts/makepkg.sh.in in e19d7da4~1\n> >\n> > Same deal, scripts/makepkg.sh.in didn't exist in e19d7da4~1 either, it\n> > got renamed from scripts/makepkg.in in b5f8a44be\n> \n> That was my whole point here- I was stabbing in the dark so I showed\n> you everything I tried because the git-annotate manpage failed me.\n> \n> >> Help? Or do I need to think about writing some sort of patch for it?\n> >> This is the first thing I have seen svn be able to do[1] that git\n> >> can't. :)\n> >\n> > Uhm, no, svn fails in the exact same way, not quite unexpected.\n[...]\n> > doener@atjola:h $ svn blame file://$PWD/repo/bar\n> > doener@atjola:h $ svn blame file://$PWD/repo/bar@1\n> > svn: '/bar' is not a file in revision 1\n> \n> svn blame file://$PWD/repo/foo@1 works perfectly though, that was my use case.\n\nYeah, with the old name, and that works in git too, same deal as with\nthe previous one, I've been totally confused, sorry.\n\n> Sorry for doing like a point-by-point refute of your response here, I\n> probably wasn't clear enough in my original email.\n\nNo problem, pointing out my mistakes is the best you could do. And\nbasically, I (wrongly) did the same to your mail. ;-)\n\nBjörn\n"},{"id":"119631","messageId":"20090805165618.GB17792@atjola.homenet","threadId":"20401","inReplyTo":"449c10960908050849pa4df6c6x3f5aa4510e9a2642@mail.gmail.com","subject":"Re: blame on a deleted/renamed file","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-08-05T16:56:18Z","receivedAt":"2009-08-05T16:56:18Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.08.05 10:49:09 -0500, Dan McGee wrote:\n> 2009/8/5 Björn Steinbrink :\n> > Hm, I still don't see what you mean. For some lines it stopped at\n> > e19d7da4, yeah, but those were new lines, added in that commit, at least\n> > those that I checked (e.g. \"local ct=0\" in generate_checksums()). For\n> > the others, it already went back further.\n> \n> Thought I'd just clarify the lines off-list that I actually cared about:\n> \n> # fix flyspray #6246\n> local file_type=$(file -bizL \"$file\")\n> local cmd=''\n> case \"$file_type\" in\n> *application/x-tar*|*application/zip*|*application/x-zip*|*application/x-cpio*)\n> cmd=\"bsdtar -x -f\" ;;\n> *application/x-gzip*)\n> cmd=\"gunzip -d -f\" ;;\n> *application/x-bzip*)\n> cmd=\"bunzip2 -f\" ;;\n> *application/x-xz*)\n> cmd=\"xz -d -f\" ;;\n> *)\n> # Don't know what to use to extract this file,\n> # skip to the next file\n> continue;;\n> \n> Which moved in that commit into a bash function, and I wanted to trace\n> them back further.\n\nAh, ok. Most of these got changed later, so the blame is right for them,\nbut for example the *application/x-gzip*) line was just literally moved\nin the file, and blame should be able to follow at least that one. And\nit does that as long as you don't cross commit\n68c10690eae369928b6cdc2d658588ad06e4b1a5, which changed the cmd=\"...\"\nlines. Even with -M5 -C5 -C5 -C5 (which should set the scores low\nenough, and enables the hardest following mode) it starts to blame that\nline to e19d7da4 then. The same is true if you blame too few lines.\n\ngit blame -M5 -C5 -C5 -C5 -w -L/x-gzip/,+3 \\\n\t68c10690eae369928b6cdc2d658588ad06e4b1a5^ -- scripts/makepkg.sh.in\n\nvs.\n\ngit blame -M5 -C5 -C5 -C5 -w -L/x-gzip/,+2 \\\n\t68c10690eae369928b6cdc2d658588ad06e4b1a5^ -- scripts/makepkg.sh.in\n\nThe first one follows back to 7ed7977e, the other stops at e19d7da4.\n\nI wonder whether that's a plain limitation, or a bug...\n\nBjörn\n"},{"id":"119637","messageId":"7vskg69nq6.fsf@alter.siamese.dyndns.org","threadId":"20401","inReplyTo":"449c10960908050516k25ef0a92sd8616de29a93ea5f@mail.gmail.com","subject":"Re: blame on a deleted/renamed file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-05T17:25:53Z","receivedAt":"2009-08-05T17:25:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dan McGee writes:\n\n> $ git annotate --follow \"scripts/makepkg.in\" e19d7da4~1\n> fatal: cannot stat path 'scripts/makepkg.in': No such file or directory\n\nSyntax error. \"git blame e19d7da4~1 -- scrits/makepkg.in\".\n"}]}