Re: blame on a deleted/renamed file

From: Dan McGee <dpmcgee@gmail.com>
Date: Aug 5, 2009, 13:54 UTC
Message-ID: <449c10960908050654v3823da76p1ddb5a2bbb5c323d@mail.gmail.com>
In-Reply-To: <20090805123754.GA13340@atjola.homenet>

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