Avoid using diff to figure out files that changed in a revision.

[jgraham]

In a history with a complex merge structure, trying to figure out
which files changed using git diff appears to be fraught with peril,
since it tends to show changes on both sides of the merge. With
e.g. PR 7579 where the branch was long-lived this ends up considering
most of the repository as changed and causes the command to fail. A
simple approach that seems to be reliable is to use git log
--name-only, with --first-parent to handle merges in a predicatable
way.

---

This change is 

[gsnedders]

Do we not want something analogue to git diff $(git merge-base origin/master FETCH_HEAD)..FETCH_HEAD? Talking to @jgraham it sounds like the problem is in finding the merge-base rather than the diff?

[gsnedders]

I think this is completely the wrong solution, as it relies on everything on master being the first parent, and given the whole issue here is when branches have weird histories and this just trades it for another issue. See my forthcoming PR for another attempt at fixing this.

[gsnedders]

That PR is now #10950

[jgraham]

I think irespective of the other changes, this is safer in that it's less likely to include random crap because git log allows us to take one branch in the face of a merge whereas git diff doesn't. Having said that, if you have random merges in your history we should just reject the PR.