Last modified: 2012-05-10 22:41:02 UTC
Take https://en.wikipedia.org/wiki/Special:Version Right now (Sun May 6 19:49:36 UTC 2012) it says for MediaWiki core: 1.20wmf1 (82f3370) 82f3370 links to https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;h=82f3370 which gives 400 - Unknown action Extensions are fine.
When a git repository pulls new commits from another repository (in this case the clone on wmf pulls from gerrit), it sometimes creates a merge commit. This commit is not in the upstream repository and doesn't make any actual changes. Not sure how it can be prevented, other than to have someone with shell access do: > $ git pull origin <branch> -f (forced pull) and confirm with: > $ git log -n2 compare with https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=log;h=refs/heads/wmf/1.20wmf1
This is not git or gerrit's fault, it's Special:Version's fault.
Any hints how can I reproduce this problem locally? I have checked out 1.20wmf trunk, but Special:Version points to a61dbee41a61cdebb4744ef7273b7487bfef458d which does not exhibit this problem.
*** Bug 36749 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > This is not git or gerrit's fault, it's Special:Version's fault. It's not, see bug 36749 comment 1. Krinkle's theory in comment 1 on this bug was exactly right: both the wmf1 and wmf2 checkouts were messed up with people creating local cherry-picks that they then resubmitted (but based against a different parent) through Gerrit. So there was a commit that was on the fenari checkout but not in the remote, which caused git pull to create a merge commit every time it updated, and those merge commits are of course also local to fenari. I fixed the weird repo state, Special:Version now links to a different commit that does actually exist in the remote.