Eli Barzilay wrote: > Using `--no-merges' helps in > avoiding the confusing parts, but that's dangerous in omitting > non-trivial merges too -- and those are probably even more worth > noting than other changes (just because they'll highlights changes > that are "hotter" in the sense of more people working on that code). > > The only way I've seen to distinguish the two is to use `git show' and > see if there is no diff output (eg, "git show --pretty=format: $rev"). > But that doesn't help in getting the list of modified files. Maybe --name-only or --name-status can help. Note that most conflicts will not show up here: if the merge result matches either parent, then git diff --cc and friends will not consider it interesting at all. A command to list conflicts and their resolutions would be expensive but valuable, I think. A naïve implementation would involve redoing the merge. [...] > Is there *any* way to get `git diff --stat' to do the same thing that > `git show' does? (Or a way to get `git show --stat' not show all > files again...) A “merge diffstat” sounds like an interesting idea, but the detailed semantics are not obvious to me (maybe separate counts for nontrivial added and removed lines from each parent?). Thanks for the food for thought, Jonathan -- 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