Wolfgang Rohdewald <wolfgang@xxxxxxxxxxxx> writes:
> 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.
--
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