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 -- 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