Re: Feature request: implement '--follow' option for `git blame`

KES <kes-kes@yandex.ua> writes:

Suppose you have file A and file B in your version v1.0.

Six month down the road, the code was much refactored, and you do not need the contents of these two files separately. You have removed A and B and much of what they had is now in file C. That is the current state.

    git blame -C HEAD -- C

may follow the contents from both just fine, but if you _were_ allowed to say

    git blame v1.0 -- C

what does it even mean? C did not exist v1.0 at all. Are you asking to follow the contents of A back then, or B? How did you tell you meant A and not B when you told it C in this command?

"git blame" follows content movements, and never treats "renames" in any special way, as it is a stupid thing to do to think a rename is somehow special ;-)

The way you tell what content to start digging from to the command from its command line is to give starting point commit (defaults to HEAD but you may give COMMIT^ as your example) and the path in that starting point. As it does not make any sense to tell C to Git and then magically make it guess you meant A in some cases and B in some other. If v1.0 did not have C, the only sensible thing to do is to exit instead of making a guess (and without telling the user how it guessed).