From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 18 Jul 2016 18:49:28 GMT
Subject: Re: [PATCH] blame: Allow to blame paths freshly added to the index
Message-ID: <xmqqbn1ukchz.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160715231656.iztvtftk5ttrzeow@glandium.org>

Mike Hommey <mh@glandium.org> writes:

>> I suspect that this would be useful without copy detection.  If you
>> "git mv fileA fileB" (optionally followed by "edit fileB"), fileB
>> would not be in HEAD but you should be able to trace the lineage of
>> the lines in it back through the renaming event, and this change
>> also allows that use case, no?
>
> It should, but that'd be copy/move detection, wouldn't it? :)

Actually, in the context of "git blame", there is no extra
"detection" needed for following a whole file rename.

>> But the user can be in the same conflicted rename situation with
>> "git am -3" or cherry-pick, and in these cases there won't be extra
>> parent commits for the fake work tree commit, hence the conclusion
>> does not change.
>
> Indeed, with cherry-pick, the "no such path in HEAD" error is happening
> with the patch.

OK.