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

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 36575 - Special:Version on shows a git commit that isn't in the public repository on gerrit/gitweb
Special:Version on shows a git commit that isn't in the publ...
Product: Wikimedia
Classification: Unclassified
Git/Gerrit (Other open bugs)
All All
: Low major (vote)
: ---
Assigned To: Nobody - You can work on this!
: 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: ---


Description Marcin Cieślak 2012-05-06 19:51:56 UTC

Right now (Sun May  6 19:49:36 UTC 2012) it says for MediaWiki core:

1.20wmf1 (82f3370)

82f3370 links to;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;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.