Re: blame on a deleted/renamed file
2009/8/5 Björn Steinbrink <B.Steinbrink@gmx.de>:
Show 13 quoted lines
> 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.
Show 9 quoted lines
>> 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...
Show 5 quoted lines
>> $ 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.
Show 30 quoted lines
>> 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
Dan McGee
