Suppose you're getting the latest version of a file from source control and a conflict occurs. There are four possible types of changes in the conflict:
Naturally, in cases 3 and 4 you'd want to review the changes manually (in the latter case you even have to resolve it). Regarding cases 1 and 2 I'm not sure, but I'm thinking only changes of type 2 (Theirs) should prompt manual inspection. The reason being, you know what you changed, as opposed to "their" changes which may break your changes. So I'm thinking one could skip reviewing his own changes (case 1), and manually review / resolve the other changes (cases 2-4).
Other developers suggested more extreme approaches - such as only reviewing conflicting (or "both") changes and trusting automerge for the rest. The other extreme is reviewing all the changes every time.
Of course, other parameters may factor in. For example, if you only made a single correction to a file, and there are 200 changes made by others, then provided you can be reasonably sure that your change is unrelated (say it's an SQL file and you wrote a new separate stored procedure), perhaps you can skip reviewing the other changes.
I am torn between the dangers of not inspecting changes and the time and energy that could be saved by trusting the automatic merge. Supposedly, you have compilation and unit/component/e2e tests that will expose bad merges.