Gerrit/Troubleshooting/ha
Wannan shine wurin tsakiya don rubuta matsala tare da Git, Gerrit da git-review.
ssh
Bad server host key: Invalid key length
If you receive this error when testing ssh such as:
tony@thor:~$ ssh -p 29418 shelluser@gerrit.wikimedia.org
Bad server host key: Invalid key length
Try reducing the Minimum RSA Key length, such as:
$ ssh -p 29418 -o RequiredRSASize=1024 shelluser@gerrit.wikimedia.org
The authenticity of host '[gerrit.wikimedia.org]:29418 ([208.80.154.151]:29418)' can't be established.
RSA key fingerprint is SHA256:j7HQoQ6fIuEgDHjONjI2CZ+2Iwxqgo2Ur5LbPqBgxOU.
No matching host key fingerprint found in DNS.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[gerrit.wikimedia.org]:29418' (RSA) to the list of known hosts.
**** Welcome to Gerrit Code Review ****
Hi AccountName, you have successfully connected over SSH.
Unfortunately, interactive shells are disabled.
To clone a hosted Git repository, use:
git clone ssh://shelluser@gerrit.wikimedia.org:29418/REPOSITORY_NAME.git
Connection to gerrit.wikimedia.org closed.
$
You can save this configuration permanently by editing your ~/.ssh/config:
# Work around error: Bad server host key: Invalid key length
Host gerrit.wikimedia.org
RequiredRSASize 1024
git clone
fatal: The remote end hung up unexpectedly
See https://stackoverflow.com/questions/6842687/the-remote-end-hung-up-unexpectedly-while-git-cloning for some ideas, and debug the problem by setting the GIT_TRACE=1 environment variable.
The authenticity of host '[gerrit.wikimedia.org]:29418 (....)' can't be established.
The authenticity of host '[gerrit.wikimedia.org]:29418 ([2620:0:861:2:208:80:154:137]:29418)' can't be established.
RSA key fingerprint is SHA256:j7HQoQ6fIuEgDHjONjI2CZ+2Iwxqgo2Ur5LbPqBgxOU.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
In this case, please check if the value given in the line "RSA key fingerprint is SHA256:j7HQoQ6fIuEgDHjONjI2CZ+2Iwxqgo2Ur5LbPqBgxOU" matches the fingerprint published on the wikitech:Help:SSH_Fingerprints/gerrit.wikimedia.org:29418.
Idan ƙimar ɗaya ce, kawai danna yes.
If for some reason the values are not the same, there is a security risk and you stop trying to connect immediately.
scp of commit-msg hook fails with "subsystem request failed on channel 1"
Gerrit's Clone with commit-msg hook copy/paste commands include a scp[1] command that downloads the commit-msg file to the local repository.
Buɗe nau'ikan SSH>=9 ba za su gaza ba kamar yadda scp zai yi ƙoƙarin yin amfani da sftp tunda an cire scp.
Don zazzage fayil ɗin, ƙara -O zuwa umarnin. For example,
scp -O -p -P 29418 username@gerrit.wikimedia.org:hooks/commit-msg "projectname/.git/hooks/"
git pull
Please, commit your changes or stash them before you can merge.
To discard your changes (and anything you had in the stash):
git stash
git stash clear
Now you can proceed with your pull.
git-review
git-review ya koka game da matsalolin da aka fuskanta wajen shigar da ƙugiya commit-msg =
Idan kun haɗu da wannan kuskure lokacin ƙoƙarin tura canje-canje ta amfani da git-review, ba kwa aiki tare da ma'ajiyar da aka rufe ta ssh. Dole ne ku rufe ma'ajin ta amfani da ssh, ba http ko https ba, don samun nasarar tura canje-canje ta amfani da git-review.
git-review ya koka game da "ɓacewar Change-id a saƙon ƙaddamarwa" =
If upon doing 'git review' you receive a message about 'missing Change-Id', then your /.git/hooks/commit-msg is probably incorrect. It should look something like:
CHANGE_ID_AFTER="Bug|Issue"
MSG="$1"
# Check for, and add if missing, a unique Change-Id
#
add_ChangeId() {
clean_message=`sed -e '
/^diff --git a\/.*/{
s///
q
}
/^Signed-off-by:/d
/^#/d
' "$MSG" | git stripspace`
if test -z "$clean_message"
then
return
fi
You will also get a missing Change-ID message when trying to merge (git cherry-pick) some change from git that does not have Change-ID.
It seems that the hook isn't called by cherry-pick, but it is fortunately called by git commit -c commit-id.
In the example below we will be moving trivial change bd7a268e4be2da23ba0b9943c3b0ba1ac88294dc from git master in the mediawiki/core project to REL1_19.
To fix this, use -n (don't commit) option to git cherry-pick:
git cherry-pick -n bd7a268e4be2da23ba0b9943c3b0ba1ac88294dc
git commit -c bd7a268e4be2da23ba0b9943c3b0ba1ac88294dc
Unfortunately, if you want to add the original commit ID to the message (as done by git cherry-pick -x) you have to add it yourself.
If you forgot to run git review -s, "remote" will complain about "missing Change-id in commit message".
But it will also suggest a commit message with a Change-Id: INNNXXXNNN... line.
Either:
- Copy that line starting with "Change-Id", run
git commit --amend, and paste the Change-Id line under your commit message in the text editor that opens up. - Or it will suggest a hook fix:
gitdir=$(git rev-parse --git-dir); scp -p -P 29418 freephile@gerrit.wikimedia.org:hooks/commit-msg ${gitdir}/hooks/
You should be able to use either method (but the hook didn't work for me), then repeat git review -R, and it should complete.
git-review yayi korafi "Kuna da alƙawari fiye da ɗaya da kuke shirin ƙaddamarwa" =
If git review displays a warning about multiple commits, followed by a list of other people's commits that have already been merged, perform the following workaround:
- Respond "no" to abort git-review.
- Run
git fetch --allorgit remote update(Both commands do exactly the same thing, they fetch objects from all remote repositories set; so just pick the command you remember easily and forget about the other one.) - Rerun
git-review
Wannan zai tabbatar da cewa git-review yana da ra'ayi na zamani na maigidan nesa.
Background
Wannan shi ne da aka gyara a cikin 2012 amma bug ya dawo.
Wikimedia projects suffer from this disproportionately because defaultrebase=0 is set on most Wikimedia projects, and the bug only triggers when rebasing is disabled (using either that setting or the -R flag).
git-review ya koka "Ba za a iya tambayar facin bayanin" =
git-review ba ya aiki daidai idan git ya haifar da fitowar da ba na Ingilishi ba. You will see an error like this:
$ git review -d 62474
Cannot query patchset information
The following command failed with exit code 255
"ssh -x -p None gerrit query --format=JSON --current-patch-set change:62474"
-----------------------
Bad port ' None'
-----------------------
Wannan ya faru ne saboda kwaro a cikin git-review.
To work around this on a Linux system, either apply the patch from the bug report above, or set up an alias that forces git to use English output.
To do so, put this into your bashrc or similar setup file:
alias git="LANG=C git"
git-review yayi korafi "ConfigParser.NoSectionError: Babu sashe: 'sabuntawa'" =
If this happens (phab:T57732, fixed in newer git-review versions):
$ git review -s
Traceback (most recent call last):
File "/usr/local/bin/git-review", line 1196, in <module>
main()
File "/usr/local/bin/git-review", line 1108, in main
needs_update = latest_is_newer()
File "/usr/local/bin/git-review", line 179, in latest_is_newer
if not configParser.getboolean("updates", "check"):
File "/usr/lib/python2.7/ConfigParser.py", line 368, in getboolean
v = self.get(section, option)
File "/usr/lib/python2.7/ConfigParser.py", line 607, in get
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'updates'
Adding something like this to ".gitreview" fixes the problem:
[updates]
check=off
git-review baya son hada hannu =
If you merged a development branch, and now want to submit a merge commit to Gerrit, git review may not let you.
It may ask you for submitting lots of changes from one of the merged branches, or otherwise mangle the commit.
To avoid this, push the commit directly to Gerrit, bypassing git review:
git push gerrit HEAD:refs/for/master
For more information, see the Gerrit documentation.
git-review ya koka "Bishiyar aiki datti" =
If upon doing 'git review' you receive a message "Working tree is dirty" try doing 'git add' for the file(s) changed (or created), then git commit, and then git review.
(This was seen on Mac OS X with an older git client.)
git-review ya yi korafin "An kasa tantancewa" =
If you see
remote: Unauthorized
fatal: Authentication failed for 'https://gerrit.wikimedia.org/r/some/code/repository'
then you are trying to push via HTTPS instead of SSH which you had set up earlier. You likely want to configure git to use the SSH remote instead of the HTTPS remote.
Gerrit
Gerrit complains that "Your change could not be merged due to a path conflict"
You have to rebase your change in order to be able to merge it.
For the impatient:
git checkout master git pull git-review -d <change #> git rebase origin/master git status <edit "both modified" files in status report> git add <files> git rebase --continue git review
Full explanation
So you have submitted a change and was approved. But by the time it gets reviewed other commits have altered the main repository which now cause a conflict. Gerrit is unable to automatically merge your change into the repository, you will have to fix it and resubmit the change.
The example below is based on a real use case : change 2514 using the operations/puppet repository
First fetch the change using git-review and its -d option :
(production)$ git-review -d 2514
Downloading refs/changes/14/2514/1 from gerrit into review/hashar/ignore_pyc
Switched to branch 'review/hashar/ignore_pyc'
(review/hashar/ignore_pyc)$
hashar is the user name, ignore_pyc the topic name he gave.
Lura yadda git-review ta sanya ku zuwa reshe ta atomatik.
You now have to rebase on top of the main branch.
The change on gerrit shows the branch, just add "gerrit/" in front.
For this change in the operations/puppet repo, the main branch is "production", so rebase on gerrit/production; for other repos it's usually origin/master.
(review/hashar/ignore_pyc)$ git rebase gerrit/production
First, rewinding head to replay your work on top of it...
Applying: pyc files are now ignored
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging .gitignore
CONFLICT (content): Merge conflict in .gitignore
Failed to merge in the changes.
Patch failed at 0001 pyc files are now ignored
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".
(no branch)$
The key in the above output is the line starting with CONFLICT.
It tells you the filename that git couldn't cleanly rebase, usually because your patch alters it and changes in the main branch have also altered it.
Running git status confirms it:
(no branch)$ git status
# Not currently on any branch.
# Unmerged paths:
# (use "git reset HEAD <file>..." to unstage)
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: .gitignore
#
(no branch)$
Edit the conflicting file (in this case .gitignore).
This will have <<<<, ==== >>> markers surrounding the conflicting lines, you must clean this up.
During the merge conflict git creates file.BASE.xxx, file.LOCAL.xxx, and file.REMOTE.xxx files with the three source versions.
You can use a three-way merge tool to pick which lines to use;
git mergetool yana kunshe da amfani da kayan aikin haɗin gwiwa.
Once you have finished editing, you have to add that modification to have it used during the rebase then continue fixing any conflicting patches:
(no branch)$ git add .gitignore
(no branch)$ git rebase --continue
Applying: pyc files are now ignored
(review/hashar/ignore_pyc)$
Since there was no more patches to fix, you have been placed back in the review/hashar/ignore_pyc branch. Looking at the log:
$ git log -n5 --decorate --pretty=oneline
* a3631d2 (HEAD, review/hashar/ignore_pyc) pyc files are now ignored (2 seconds ago
* 1b6cd67 (gerrit/production, production) ensure sample config file removed (18 hours ago)
...
Verify your change looks fine before resubmitting it to gerrit.
Yi amfani da git show <sha1 of commit> kawai, watau git show a3631d2.
You can eventually amend it to state you have rebased the change.
Now submit your change back in the repository:
(review/hashar/ignore_pyc)$ git review
remote: Resolving deltas: 0% (0/2)
To gerrit.wikimedia.org
(review/hashar/ignore_pyc)$
Heading back to Gerrit, the change is a new patchset pending review.
Congratulations on fixing your first rebase / merge conflict!
In Gerrit your change is not merged after receiving a +2
If someone enters +2 Code Reviewed, it should trigger a series of automated builds and tests. Continuous integration/Workflow describes the flow.
A Gerrit, "mai amfani" jenkins-bot ya kamata ya ƙara sharhi
- Starting gate-and-submit jobs. https://integration.wikimedia.org/zuul/
Follow the link to see the progress of the tests for your change that Zuul has submitted to Jenkins.
If you don't see the "Starting gate-and-submit jobs" comment in gerrit, look at https://integration.wikimedia.org/zuul/ It shows everything that Zuul has submitted to Jenkins, and the "Queue length" number on top is the number of events not yet processed. If your job doesn't appear below this on the page below but the queue length is non-zero, it is likely in the queue; Zuul and Jenkins are probably busy and you just have to wait. But if the queue length is 0 and your change doesn't appear, it means it isn't going to happen and you need to resubmit it. Lura cewa sabbin wuraren ajiyewa dole ne su kasance da hannu da hannu zuwa jerin jenkins-bot.
Idan gwaje-gwajen da ake buƙata duk sun wuce (lura cewa wasu "ba masu jefa ƙuri'a ba ne"), to jenkins-bot zai ƙara sharhi "Build succeeded" sannan "Change has been successfully merged into the git repository." ya biyo baya.
In Gerrit Jenkins gave a -2 so you need to override Jenkins
First of all, you should more or less never do this. (So far the reason was backporting a change to an old release that had broken tests). If Jenkins has a -2 you generally can't merge the change. What you need to do:
- Cire bita jenkins-bot "Verified" (danna
[x]) - Review the latest patch set with "Verified +2" in addition to "Code-Review +2" (this is normally reserved for Jenkins, but since we are overriding it we are replacing its score with our own)
- Click "Publish and Submit"
"Permission denied (publickey)" error
In general you should check SSH verbose output with ssh -v -p 29418 <username>@gerrit.wikimedia.org (you can get more details with -vv/-vvv but usually debug level 1 is enough).
There are many reasons you can get this error, most of them related to local misconfiguration, like your SSH key not being readable, or not matching the one you uploaded to Gerrit, or using an outdated algorithm (see also T276486).
fatal: Could not read from remote repository.
If you get the error
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
First of all, if you are on Windows, make sure to use Git Bash as a command line tool.
OpenSSH disabled support for old id_rsa keys since version 8.8.
ssh-keygen however will continue to generate RSA keys when used without arguments.
Such keys will just be ignored, resulting in the cryptic error message above.
You need to either create a new id_ed25519 key as described in the Gerrit tutorial (recommended) or re-enable support for RSA keys with OpenSSH's HostkeyAlgorithms option, as described in the release notes.
Then please share the output of the command git remote show origin, run the affected git command with debug logging variables such as GIT_CURL_VERBOSE=1 GIT_TRACE=1, and test if ssh -p 29418 username@gerrit.wikimedia.org (replace username in that command with your developer account's username) shows Hi username, you have successfully connected over SSH.
fatal: The remote end hung up unexpectedly
If you get the error
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
Then you are not logged in to your ssh key right now.
Solution: do ssh-add ~/.ssh/id_rsa to make it prompt you for the passphrase for your key and add it to the active keychain.
Then you can check what's in your keychain with ssh-add -l.
Then try pushing for review again.
The fingerprint of the Gerrit server is
dc:e9:68:7b:99:1b:27:d0:f9:fd:ce:6a:2e:bf:92:e1
so you can say yes when it asks you to add that fingerprint to the known_hosts file.
Keep in mind that gerrit listens on port 29418 and if for some reason you forgot to specify port number, you might be hitting "normal" SSH daemon listening on port 22 (this one has RSA key fingerprint b5:e9:dc:b2:dd:6e:70:f7:18:8a:dc:a3:5d:ab:99:4d).
To check whether SSH connectivity and public key authentication, use ssh -p 29418 username@gerrit.wikimedia.org which should show Hi username, you have successfully connected over SSH.
Your change is not having tests run
Tests are only run users in the CI[2] allow list. See Continuous integration/Allow list for more information.
Miscellaneous
Push using HTTPS (when SSH is not functional)
| Extended content |
|---|
|
This method is helpful for submitting to changes to Gerrit when SSH is not functional (for example SSH is blocked by your institution or internet provider). If SSH is not working, you should see one of these error messages: ssh: connect to host gerrit.wikimedia.org port 29418: Connection refused ssh: connect to host gerrit.wikimedia.org port 29418: Network is unreachable You can also explicitly try the command ssh -p 29418 your-user-name@gerrit.wikimedia.org
If SSH is functional, that command should create the following output: Connection to gerrit.wikimedia.org closed by remote host. Connection to gerrit.wikimedia.org closed. When SSH is not functional, you need an HTTP(S) Password which can be generated in the Account Settings of Gerrit under "HTTP Password". After generating the password, commit all the changes for your patch(s) and use git push https://<username>@gerrit.wikimedia.org/r/mediawiki/core HEAD:refs/for/master The authentication credentials need to be entered to successfully submit the changes. The url given above is for MediaWiki core and will vary for extensions accordingly. For example if you want to push to Extension:LiquidThreads the command would be git push https://<username>@gerrit.wikimedia.org/r/mediawiki/extensions/LiquidThreads HEAD:refs/for/master To always use https, initially clone with: git clone https://<username>@gerrit.wikimedia.org/r/mediawiki/core Or adjust an existing repository with: git remote set-url origin https://<username>@gerrit.wikimedia.org/r/mediawiki/core Then you can use You can use git-credential-store to store your HTTPS password so you don't have to type it in every time.
Sanya Kugiya da Change-Id =A major problem that arises when using HTTPS for submitting changes is that commit hook is not automatically attached. A hack for this approach is to make one fail attempt to push. Lokacin yin haka, saƙon kuskure zai haskaka Change-Id ta atomatik, duba misali na ƙasa: Username for 'https://gerrit.wikimedia.org': xxxxxx Password for 'https://xxxxxx@gerrit.wikimedia.org': Counting objects: 25, done. Delta compression using up to 2 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 448 bytes | 0 bytes/s, done. Total 4 (delta 3), reused 0 (delta 0) remote: Resolving deltas: 100% (3/3) remote: Processing changes: refs: 1, done remote: ERROR: missing Change-Id in commit message footer remote: Suggestion for commit message: remote: Commit message appears here remote: remote: Change-Id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx remote: remote: Hint: To automatically insert Change-Id, install the hook: remote: gitdir=$(git rev-parse --git-dir); scp -p -P 29418 xxxxxx@gerrit.wikimedia.org:hooks/commit-msg ${gitdir}/hooks/ remote: remote: To https://gerrit.wikimedia.org/r/mediawiki/extensions/Test ! [remote rejected] HEAD -> refs/for/master (missing Change-Id in commit message footer) error: failed to push some refs to Now copy the change ID and amend your commit. Koyaushe ƙara Change-Id azaman layin ƙarshe na saƙonku. git commit --amend This will open an editor to change the commit message. Manna Change-Id azaman layin ƙarshe na saƙon kuma ajiye shi. See example: Your commit summary Your commit message Bug: Txxxxx Change-Id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Now you can successfully push to Gerrit. Automatically adding commit HookDon samun rubutun commit-msg: scp -p -P 29418 USERNAME@gerrit.wikimedia.org:hooks/commit-msg <local path to your git>/.git/hooks/
Being behind a proxy serverThis section is untested; please update this section with updated information if issues arise
If you are behind a proxy server, you also need to clone over HTTPS.
Make sure the environment variable GIT_CURL_VERBOSE=1 git clone https://gerrit.wikimedia.org/r/pywikibot/core.git
In case of issues, try providing HTTPS_PROXY=proxy_server GIT_CURL_VERBOSE=1 git clone https://gerrit.wikimedia.org/r/mediawiki/core.git
or use git's options directly: GIT_CURL_VERBOSE=1 git -c http.proxy="proxy_server" clone https://gerrit.wikimedia.org/r/mediawiki/core.git
This last option should also work for SOCKS proxy servers, using GIT_CURL_VERBOSE=1 git -c http.proxy="socks5://socks_server" clone https://gerrit.wikimedia.org/r/mediawiki/core.git
|
Push using SSH only (when HTTPS is disabled not functional)
Add to your local '.gitconfig' following section:
# Use SSH over HTTPS
[url "ssh://username@gerrit.wikimedia.org:29418/"]
pushInsteadOf = https://gerrit.wikimedia.org/r/
"git commit --amend" complains "you are in the middle of a merge -- cannot amend"
When after rebasing and merging your
git commit --amend
results in
message: fatal: You are in the middle of a merge -- cannot amend.
apply these steps and reapply your changes
git stash
git reset --hard
git checkout master
git review -d <change number>
git stash pop
git commit -a --amend
Idan, bayan git review jenkins-bot imel
This change was unable to be automatically merged with the current state of the repository. Please rebase your change and upload a new patchset.
This might mean that server master branch now has merge conflicts with your patch.
Check advanced Gerrit usage to see how to fix them.
Your change requires a recursive merge to resolve
If you get the error "Your change requires a recursive merge to resolve", you need to rebase the change set against master.
- Make sure your master branch is up to date:
git pull origin master - Create and switch to a new branch in which to checkout the change set with the conflict:
git checkout -b BRANCHNAME - Checkout the conflicting change set into this branch. You can copy/paste the correct command from the 'Download' section in the Gerrit review. It will look something like this:
git fetch ssh://awjrichards@gerrit.wikimedia.org:29418/mediawiki/extensions/MobileFrontend refs/changes/14/3414/3 && git checkout FETCH_HEAD - Rebase against master:
git rebase master - Push the change to Gerrit for review:
git review - Re-review the change set in Gerrit, and then submit the changes to be merged to master.
"[remote rejected] master -> master" and "failed to push some refs"
If push to a branch other than refs/for/master, you will receive something along the lines of:
$ git push
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 709 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 0% (0/1)
To ssh://username@gerrit.wikimedia.org:29418/test/mediawiki/extensions/examples
! [remote rejected] master -> master (prohibited by Gerrit)
error: failed to push some refs to 'ssh://username@gerrit.wikimedia.org:29418/test/mediawiki/extensions/examples'
This means you tried to commit to branch "master" instead of submitting your changes for review.
The following is a similar error where git review was trying to push to a non-existing remote branch:
! [remote rejected] T12345 -> T12345 (prohibited by Gerrit)
error: failed to push some refs to 'ssh://username@gerrit.wikimedia.org:29418/test/mediawiki/extensions/examples'
You can see with git branch what's the branch you are currently using. Try rebasing to push correctly:
git pull --rebase origin master
git review -R
[remote rejected] HEAD -> refs/publish/master/??? (Cannot merge change to another branch)
When attempting to cherry-pick a change or merge an entire branch and then submit for review; gerrit will be very confused if you do not explicitly tell it what branch you are modifying. You might get errors like:
! [remote rejected] HEAD -> refs/publish/master/mwalker_test (change 59546 closed)
or
! [remote rejected] HEAD -> refs/publish/master/mwalker_test (no new changes)
In this case you must ensure that your branch's .gitreview file has the correct defaultbranch option (e.g. it should be pointing to the branch you are attempting to modify) or you must manually push the refspec using git push gerrit HEAD:refs/for/<branch>
! [remote rejected] HEAD -> refs/publish/master (prohibited by Gerrit: not permitted: create)
Idan kuna amfani da git-review don ƙaddamar da faci zuwa gerrit, tabbatar cewa kuna da 1.27 ko sabo (ba 1.26 ba). git-review 1.26 baya aiki tare da Gerrit 3.
! [remote rejected] HEAD -> refs/changes/79/550379/2 (cannot add patch set to 550379.)
Wannan yana faruwa idan ba kai ne ainihin marubucin (mai shi) na canji (a wannan yanayin 550379). Don samun damar ƙara sabon saitin faci zuwa alƙawarin da ba ku yi ba, da fatan za a nemi ƙari ga ƙungiyar Trusted-Contributors akan Gerrit. Every member of this group is able to add you on request.
Adireshin imel na kwamitocin bai dace da asusun mai amfani ba.
remote: ERROR: committer email address (email) remote: ERROR: does not match your user account.
There are two possible problems that could cause this error. If the email address that git pops back _is_ the email address you intend to use with Gerrit, then you should add that email address in Gerrit, and make sure you click the confirmation link in the email Gerrit sends you. Then try pushing again.
If, however, git sends back some nonsense email (like one you don't use anymore, or a local mail address like root@localhost), you should do the following:
$ git config --global user.email yournewemail@example.org
$ git commit --amend --reset-author
To do it locally for just that repo, instead do:
$ git config user.email yournewemail@example.org
$ git commit --amend --reset-author
Then, try pushing again.
Build failed due to merge conflict
Bayan 'git review` jenkins-bot imel This change was unable to be automatically merged with the current state of the repository. Please rebase your change and upload a new patchset. This might mean that server master branch now has merge conflicts with your patch.
- Make sure your master branch hard-reset to the gerrit's master (to avoid git review complaining about multiple commits)
$ git checkout master
$ git fetch --all
$ git reset --hard origin/master
- Checkout for review, rebase, recommit
$ git review -d <patchNumber>
$ git rebase master
# Fix merge conflicts and add them with 'git add'
$ git rebase --continue
$ git review -R
If the error occurs even though you have rebased your patch as above, try making an arbitrary change to your commit message, and then running git review again (related to bug 53895).
"Everything up-to-date" message after git push
If you attempt to do 'git push' after doing 'git commit' you may receive a response 'Everything up-to-date'. You have not pushed to the branch. You have to do 'git review' to move your changes to gerrit, and only from gerrit will the branch be updated. This seems to be a side effect of checking out master as a branch as of February 2012.
In some projects (e.g. test/) it is possible to do 'git push' instead of 'git review' and have the push succeed. It is probably better not to do that, as it confuses those who find your changes later and don't know where they came from.
Tagging an extension doesn't work
If you want to tag your extension, you need to connect to gerrit using ssh, not https. In your .git/config, the remote url should look like this:
[remote "origin"]
url = ssh://username@gerrit.wikimedia.org:29418/r/mediawiki/extensions/yourextension
fetch = +refs/heads/*:refs/remotes/origin/*
To tag an extension, use git tag followed by git push:
git tag -a v1.4 -m 'my version 1.4'
git push --tags
Plugin install error: TypeError: self.onAction is not a function
If you see this error please hard refresh your browser cache.
For some the Ctrl + F5 or Shift + Ctrl + F5 (or whatever combination your browser wants) is not sufficient.
If you still run into the issue after pressing your browsers F5 combination, please try clearing your caches for good.
For example on Firefox follow steps 1-6 from
If you use a different browser, it should allow you to clear cached web content somewhere in the setting too. Please find that in your browser's help pages and follow the instructions.
Bad server host key: Invalid key length
Users who are using Fedora 33 or later with the DEFAULT or FUTURE crypto settings are unable to use Git over SSH on Gerrit.
(related to T326204)
Affected users can work around this issue by decreasing the minimum key length requirement for gerrit.wikimedia.org specifically in their ~/.ssh/config file:
Host gerrit.wikimedia.org
RSAMinSize 1023