Gerrit/Fehlerbehebung

This page is a translated version of the page Gerrit/Troubleshooting and the translation is 1% complete.

Dies ist der zentrale Ort, um die Fehlerbehebung bei Problemen mit Git, Gerrit und git-review zu dokumentieren.

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.

If the values are the same, just press 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. OpenSSH versions >=9 will fail as scp will attempt to use sftp^[2] since scp has been deprecated. To download the file, add a -O to the command. Zum Beispiel,

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 complains about problems encountered installing commit-msg hook

If you encounter this error when trying to push changes using git-review, you are not working with a repository that was cloned via ssh. You must clone repositories using ssh, not http or https, to successfully push changes using git-review.

git-review complains about "missing Change-id in commit message"

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 complains "You have more than one commit that you are about to submit"

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 --all or git 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

This will ensure git-review has an up-to-date view of the remote master.

Background

This was fixed in 2012 but the bug returned. 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 complains "Cannot query patchset information"

git-review does not work correctly if git generates non-English output. 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'
-----------------------

This is due to a bug in 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 complains "ConfigParser.NoSectionError: No section: 'updates'"

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 doesn't like merge commits

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 complains "Working tree is dirty"

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 complains "Authentication failed"

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

Gerrit does not magically resolve conflicts :)

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. Notice how git-review automatically placed you to the branch.

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 wraps the use of a merge tool.

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. Just use git show <sha1 of commit>, i.e. 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.

In Gerrit, the "user" jenkins-bot should add a comment

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. Note that new repos have to be manually added to jenkins-bot's list.

If the required tests all pass (note that some are "non-voting"), then jenkins-bot will add a comment "Build succeeded" followed by "Change has been successfully merged into the git repository."

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:

Removing the jenkins-bot "Verified" review (click the [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^[3] allow list. See Continuous integration/Allow list for more information.

Miscellaneous

Push using HTTPS (when SSH is not functional)

Due to a security incident, https push access has been (temporarily?) disabled. The following section may therefore not be applicable.

Erweiterter Inhalt

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 Erweiterung: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 git review normally.

You can use git-credential-store to store your HTTPS password so you don't have to type it in every time.

Commit Hook and 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. On doing so, the error message will automatically highlight the Change-Id, see below example:

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. Always add Change-Id as the last line of your commit message.

git commit --amend

This will open an editor to change the commit message. Paste the Change-Id as the last line of the message and save it. See example:

Your commit summary

Your commit message

Bug: Txxxxx
Change-Id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Now you can successfully push to Gerrit.

Automatically adding commit Hook

To obtain the commit-msg script:

scp -p -P 29418 USERNAME@gerrit.wikimedia.org:hooks/commit-msg <local path to your git>/.git/hooks/

See https://gerrit.wikimedia.org/r/Documentation/cmd-hook-commit-msg.html for details.

Being behind a proxy server

This 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 HTTPS_PROXY is set correctly. To debug issues, try running with GIT_CURL_VERBOSE=1, e.g.

GIT_CURL_VERBOSE=1 git clone https://gerrit.wikimedia.org/r/pywikibot/core.git

In case of issues, try providing HTTPS_PROXY directly, e.g.

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

If, after git review jenkins-bot emails 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)

If you use git-review to submit patches to gerrit, make sure you have 1.27 or newer (not 1.26). git-review 1.26 does not work with Gerrit 3.

! [remote rejected] HEAD -> refs/changes/79/550379/2 (cannot add patch set to 550379.)

This happens if you are not the original author (owner) of a change (in this case 550379). To be able to add a new patch set to a commit you did not author, please request addition to the Trusted-Contributors group on Gerrit. Every member of this group is able to add you on request.

Committer email address does not match your user account.

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

After `git review` jenkins-bot emails 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 Fehler 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

https://support.mozilla.org/kb/how-clear-firefox-cache#w_clear-the-cache

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

Notes

↑ Secure copy (scp)
↑ Secure File Transfer Protocol (sftp)
↑ Continuous Integration (CI)

[scp-1] Secure copy (scp)

[sftp-2] Secure File Transfer Protocol (sftp)

[ci-3] Continuous Integration (CI)

[1]

[2]

[3]