Last modified: 2012-05-10 22:41:02 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T38575, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 36575 - Special:Version on en.wikipedia.org shows a git commit that isn't in the public repository on gerrit/gitweb
Special:Version on en.wikipedia.org shows a git commit that isn't in the publ...
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Git/Gerrit (Other open bugs)
unspecified
All All
: Low major (vote)
: ---
Assigned To: Nobody - You can work on this!
https://gerrit.wikimedia.org/r/gitweb...
:
: 36749 (view as bug list)
Depends on:
Blocks: 22596
  Show dependency treegraph
 
Reported: 2012-05-06 19:51 UTC by Marcin Cieślak
Modified: 2012-05-10 22:41 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Marcin Cieślak 2012-05-06 19:51:56 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.
Comment 1 Krinkle 2012-05-07 17:17:19 UTC
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
Comment 2 Chad H. 2012-05-07 17:30:21 UTC
This is not git or gerrit's fault, it's Special:Version's fault.
Comment 3 Marcin Cieślak 2012-05-07 18:41:50 UTC
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.
Comment 4 Marcin Cieślak 2012-05-10 22:25:34 UTC
*** Bug 36749 has been marked as a duplicate of this bug. ***
Comment 5 Roan Kattouw 2012-05-10 22:41:02 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links