Re: [PATCH] blame: Allow to blame paths freshly added to the index

Mike Hommey [off-list ref] writes:

quoted

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.

quoted

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.