Mike Hommey <mh@xxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html