how do you review auto-resolved files

["Neal Kreitzinger" <neal@rsss.com>]

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