We track changes in our overlays by comparing mtimes with the portage tree. A change made 12 days ago in `mastermirror-staging.sh` introduced a bug by regularly updating file modification times with the wrong commit date. https://gitweb.gentoo.org/infra/mastermirror-scripts.git/commit/?id=90d69e5da1e503f32c30681d066ae8762f17cc50 Take a look at `net-mail/mailman/mailman-2.1.20.ebuild` which was actually changed on 2016-01-11 by 428eada but it has an mtime of 2016-02-08 which is a date of the merge commit 438f1f7. The script used for this task is `git-restore-mtime` which is executed with the `-m` switch that results calling `git whatchanged -m`. The output assigns the last change of said file to 438f1f7 which is wrong, at least for our goals. In fact 36136 other files or directories are assigned to this commit that is a GitHub PR which added only 3 files to the portage tree. So I suggest removing the `-m` switch from invocation.
We need the -m to include merge commits, as otherwise commit mtime could move backwards or appear to never change. CC'ing dwfeed, as I think had a copy of my testcase to prove where it's needed.
git whatchanged -m output is retarded, because by default it shows what changed relative to both sides of the merge, meaning it includes what changed in master since the merge-base of the history being merged in. (Merge-base is the commit in master after which history splits into two paths.) So net-mail/mailman/mailman-2.1.20.ebuild was modified in master after the history split for the PR. This has been fixed by adding --first-parent to the git whatchanged execution, so it doesn't do this, enforcing by git hooks that the first parent is always a commit in the master branch, and by getting people to stop doing merges for the most part.
