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

From: Junio C Hamano <gitster@pobox.com>
To: Eugen Konkov <kes-kes@yandex.ru>
Cc: KES <kes-kes@yandex.ua>, git@vger.kernel.org
Subject: Re: Feature request: implement '--follow' option for `git blame`
Date: Sun, 12 Apr 2015 22:32:33 -0700	[thread overview]
Message-ID: <xmqqiod04mq6.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <209433431.20150410094038@yandex.ru> (Eugen Konkov's message of "Fri, 10 Apr 2015 09:40:38 +0300")

Eugen Konkov <kes-kes@yandex.ru> writes:

> I agree with your complex example.

Note that it is a norm, not anything complex, that we do not rename
a file wholesale.

> But it will be great to guess in simple case, when in version v1.0
> only one file A which were renamed into C half year later.

So you used to have A and somebody renamed that into C in the past.
The content of C in the current version is what you used to have in
A.

What should happen if you also have A, whose contents do not have
any relation to that old A, in today's code?

What should happen if you also used to have C, whose contents do not
have any relation to that old A or current C?

What happens if you added such random guessing and you were not so
familiar with the project history to know these unrelated A's and
C's that used to exist in the past?

Current Git _consistently_ behaves, even in the presense of anything
that can lead to confusing behaviour.  When you ask

    git blame OLD -- A

it does not matter if you have an unrelated A in the revision that
you happen to have checked out in your working tree (i.e. HEAD).
The above command line talks about the old revision OLD and A talks
about the path A in that old revision.