On 2009.08.05 08:54:09 -0500, Dan McGee wrote: > 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. Hm, I still don't see what you mean. For some lines it stopped at e19d7da4, yeah, but those were new lines, added in that commit, at least those that I checked (e.g. "local ct=0" in generate_checksums()). For the others, it already went back further. > > 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... No idea, I guess I got confused by the various makepkg.* versions :-/ Especially by the "stab in the dark" blame call. ;-) > >> $ 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: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. Yeah, with the old name, and that works in git too, same deal as with the previous one, I've been totally confused, sorry. > Sorry for doing like a point-by-point refute of your response here, I > probably wasn't clear enough in my original email. No problem, pointing out my mistakes is the best you could do. And basically, I (wrongly) did the same to your mail. ;-) Björn -- 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