how do you review auto-resolved files

When git does a merges (merge/rebase/cherry-pick) it auto-resolves same-file changes that do not conflict on the same line(s).

Technical Question: What are the recommended commands for reviewing the files that auto-resolved after a "merge"?

It seems like the commands might be different depending on the type of merge: git-merge, git-rebase, git-cherry-pick. I imagine there are three steps to the "review auto-resolutions" procedure:

(1) Determine the list of files that were changed on both sides (same-file edits) and which of those were auto-resolved during the merge. (Preferably excluding those files that merge-conflicted since you already know how you manually resolved those.)

(2) Review the auto-resolved files in full context to verify whether the auto-resolutions are desirable.

(3) Manually remediate the merge-result (auto-resolution) or redo the merge-of-that-file for any files with undesirable auto-resolutions. Perhaps an edit of the auto-resolved file is sufficient for simple remediations, but for more challenging remediations a manual redo of the merge-of-that-file would be desired.

Please advise on the proven (tried and tested) ways that others are using to verify/ensure that their auto-resolve results are correct.

Procedural/Philosophical Question: What are the pros and cons of auto-resolved files?

Currently, we address the problem up-front instead of after-the-fact by enforcing merge-conflicts on every same-file edit by means of a "user-date-stamp" on "line 1" of every source file changed by performing keyword expansion (# $User$ $Date$) in our pre-commit hook. I don't think keyword expansion or forcing merge-conflicts for every same-file edit is a common practice among git users. Therefore, this seems like somewhat of a kludgey hack. Furthermore, I assume that all git users are somehow reviewing their auto-resolutions. (There is no way I would assume that git merged my same-file edits correctly. It's great that git does-the-right-thing most-of-the-time, but that doesn't change the fact that I still have to review everything for undesirable resolutions.)

In light of this, it seems that there is no advantage to letting git auto-resolve same-file changes because the review process after-the-fact would actually be more error-prone and tedious than just manually-merging same-file edits up-front. If I force you to resolve merge-conflicts up-front then I'm ensuring the merge-resolution is deliberate (and hopefully intelligent). If I expect/assume you are going to review the auto-resolutions after-the-fact then you can neglect this because you:

  - have become complacent that git usually does-what-you-want so "you don't 
really need to do it",
  - are lazy and do it half-way,
  - forget to do it,
  - think "git magically does your work for you",
  - don't know how to do it,
  - don't even realize that anything auto-resolved or what auto-resolved,
  - decide you don't have to do it because that is what testing if for,
  - you think that your time is so valuable that an ounce-of-prevention on 
your part is not worth a pound-of-cure on the part of others.

Please comment on the pros and cons of "manual-merge up-front for same-file edits" vs. "review-and-remediate after-the-fact for auto-resolutions of same-file edits".

Thanks in advance for your replies!

v/r, neal