2009/8/5 Björn Steinbrink <B.Steinbrink@xxxxxx>: > On 2009.08.05 07:16:13 -0500, Dan McGee wrote: >> Is there no easy way in git to get a blame on a file that has either >> been renamed or deleted? I'll step through my thought process, and a >> quick google and read of the manpage returned nothing obvious. Here is >> the repository in question if it matters: >> git://projects.archlinux.org/pacman.git. I located a particular commit >> I was interested using a plain git-blame: >> $ git blame scripts/makepkg.sh.in >> >> OK, looks like lines moved around enough that we got stuck here, let's > > How did it get stuck? The output I see follows the changes the whole way > back through scripts/makepkg.in, scripts/makepkg.in and scripts/makepkg. I said nothing about it not following renames. I asked about it following *those lines*. I know it already made the jump from scripts/makepkg.sh.in to scripts/makepkg.in, sorry if I wasn't clear there. >> see what this patch did: >> $ git show e19d7da4 >> >> OK, it did a move of a bunch of lines into functions that GIT couldn't >> quite track: >> $ git annotate --follow "scripts/makepkg.in" e19d7da4~1 >> fatal: cannot stat path 'scripts/makepkg.in': No such file or directory > > Where does that --follow come from? I don't see that in the man page. It's not. The git-annotate manpage is misleading as heck though; I see now I should have went straight to git-blame instead. Why have the two commands diverged so much? Thomas Rast had it perfect when suggesting this, which works perfectly (for what I wanted): $ git blame e19d7~1 -- scripts/makepkg.in > And scripts/makepkg.in got added in e19d7da4, so its parent didn't have > it. Not sure where you are seeing that, it was changed in that revision, not added... >> $ git annotate --follow "scripts/makepkg.sh.in" e19d7da4~1 >> fatal: no such path scripts/makepkg.sh.in in e19d7da4~1 > > Same deal, scripts/makepkg.sh.in didn't exist in e19d7da4~1 either, it > got renamed from scripts/makepkg.in in b5f8a44be That was my whole point here- I was stabbing in the dark so I showed you everything I tried because the git-annotate manpage failed me. >> Help? Or do I need to think about writing some sort of patch for it? >> This is the first thing I have seen svn be able to do[1] that git >> can't. :) > > Uhm, no, svn fails in the exact same way, not quite unexpected. > > doener@atjola:~ $ mkdir h > doener@atjola:~ $ cd h > doener@atjola:h $ svnadmin create repo > doener@atjola:h $ svn co file://$PWD/repo wc > Checked out revision 0. > doener@atjola:h $ cd wc > > doener@atjola:wc $ touch foo; svn add foo; svn commit -m init > A foo > Adding foo > Transmitting file data . > Committed revision 1. > doener@atjola:wc $ svn mv foo bar; svn commit -m rename > A bar > D foo > Adding bar > Deleting foo > > Committed revision 2. > doener@atjola:wc $ cd .. > > doener@atjola:h $ svn blame file://$PWD/repo/bar > doener@atjola:h $ svn blame file://$PWD/repo/bar@1 > svn: '/bar' is not a file in revision 1 svn blame file://$PWD/repo/foo@1 works perfectly though, that was my use case. Sorry for doing like a point-by-point refute of your response here, I probably wasn't clear enough in my original email. However, thank you Thomas Rast for your suggestions, as the git-blame syntax is much more powerful and allows me to do exactly what I wanted. Does anyone object to making the following wording in the git-annotate manpage: The only difference between this command and linkgit:git-blame[1] is that they use slightly different output formats, and this command exists only for backward compatibility to support existing scripts, and provide a more familiar command name for people coming from other SCM systems. slightly stronger? git-blame destroys git-annotate as far as I can see with the "rev first then file" syntax which actually allows you to get past annotations on renamed or deleted files. -Dan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html