Re: git blame --follow

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 15, 2011, 17:30 UTC
Message-ID: <7vy64g9tqs.fsf@alter.siamese.dyndns.org>
In-Reply-To: <201103151644.44360.wolfgang@rohdewald.de>

Wolfgang Rohdewald <wolfgang@rohdewald.de> writes:

Show 8 quoted lines

> git log --follow filename
>
> shows the full history, while
>
> git blame --follow filename
>
> blames everything to the latest commit (which was
> a file rename)

Huh?

    $ git checkout master^0
    $ git mv COPYING RENAMING
    $ git commit -m renamed
    $ git blame --follow RENAMING

gives everything blamed to 075b845a COPYING (but that is probably by accident, see below). FYI,

    $ git blame RENAMING

should also blame everything to the same commit and the same COPYING file. If you get a different behaviour out of the above command sequence, there is something else going on.

I didn't know "blame" even accepted "--follow". It is entirely out of the scope of its design to take "--follow" option, as the "blame" command itself has its own and real "follow" logic that is enabled by default (i.e. it follows a whole file rename without any option), instead of the checkbox "--follow" hack that is in "git log" family of commands. You cannot even turn it off.

Perhaps the behaviour you saw comes from the internal revision traversal machinery blame uses getting confused by the use of --follow, but I am too lazy to check (and I don't think it is worth to check, as the command should follow by default).

We should just teach "blame" to ignore --follow option from the command line, without even complaining.