On Wed, Mar 24, 2010 at 7:14 AM, Neal Kreitzinger <neal@xxxxxxxx> wrote: > Scenario: "same-file auto-merge": when two different people change the > same file in their separate repos. Their changes do not conflict in the > sense that they are changes to the same lines. However, their changes do > conflict in the sense that the resulting merged logic is incorrect. You're not being pessimistic enough :-) A ".h" file that changed only on one side can cause the same logic issues > Desired Solution: > Perform same-file auto-merge and produce auto-merge results, but mark all > such auto-merged files as "unmerged" so that they must be reviewed/resolved > before a git-commit. The "unmerged" status allows git-mergetool to be run > (e.g. kdiff3) so that the merged lines can be reviewed. In this way, all > auto-merged files are reviewed. No. What you need is a full blown diff for the merge, with both sides being compared with respect to the common merge-base. That diff will be pretty big, although I'm not sure what diff options would actually produce that (but I'll bet "-m" figures somewhere). -- 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