Re: Feature request: implement '--follow' option for `git blame`
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 13, 2015, 05:32 UTC
- Message-ID
- <xmqqiod04mq6.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <209433431.20150410094038@yandex.ru>
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.