All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

TroubleShooting (Git)

From TYPO3Wiki
(Redirected from Git TroubleShooting)
Jump to: navigation, search

Setup problems

Special characters in username, "permission denied (publickey)"

If copying the hooks via ssh ends up in "permission denied (publickey)" and you have special characters (like @ or !) in your user name, these characters have to be escaped using a backslash.

Clone problems

Push problems

Push: Permission denied (publickey)

$ git push origin HEAD:refs/for/master
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

If this error happens, double check if you are using the correct SSH user name (which is your user name on and you are using an SSH key known to Gerrit. Also make sure that you are pushing onto the correct URL.

The following push command shows you the Push URL (which contain

$ git push origin HEAD:refs/for/TYPO3_4-5 -v
Pushing to ssh://<username>
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

If you are pushing to something different (probably, follow the Explanation and Help on using push.

If the Push URL is correct, your SSH key is not accepted by Gerrit.

Debugging the SSH connection

Try connecting to the server with using an SSH client (OpenSSH, Putty, etc.)

ssh -p 29418 <username>

If the output looks like this, everything is fine:

****    Welcome to Gerrit Code Review    ****

  Hi Gerrit Git, you have successfully connected over SSH.

  Unfortunately, interactive shells are disabled.
  To clone a hosted Git repository, use:

  git clone ssh://<username>

Connection to closed.

Otherwise, your SSH client does not automatically choose the right private key file. By default, ssh searches for the key in ~/.ssh/id_rsa and ~/.ssh/id_dsa.
You can manually specify it using the -i parameter:

ssh -p 29418 -i <path-to-private-key> <username>

If this works, modify ~/.ssh/config to define the file name for connections to

   User <username>
   IdentityFile ~/.ssh/<keyfile>
   Port 29418

Now the connection should work without having to specify any parameters:


If this works, pushing should work as well.

Push: invalid committer

$ git push -v origin HEAD:refs/for/master
Pushing to ssh://<username>
remote: ERROR:
To ssh://<username>
! [remote rejected] HEAD -> refs/for/master (invalid committer)
error: failed to push some refs to 'ssh://<username>'

This message simply means that your email address is not registered as an Web-Identity. If this error happens, just go to the website that the error message suggests: Register the email address you use to push (button "Register New Email") - even if it is already in the dropdownlist. Click on the link you receive via email. Be sure your are already logged in on Otherwise the link does register the email address. Check if your new identity is registered ( Pushing should work now.

You are not a committer

If you are trying to push changes and get this error message, then your email address is probably not known to the system. Open Settings > Identities in Gerrit and check the email address, which is connected to your account (you can add more of them if needed). Additionally, check your setttings in Git with the following command:

git config

If needed, change it with the following command:

git config --global

You may change the user/author of your last commit with

git commit --amend

but be sure to have set your email address in the git settings. And differ between author and commiter.

Missing Change-Id in commit message

 ! [remote rejected] HEAD -> refs/for/X/X (missing Change-Id in commit message)

If pushing a commit fails with a missing Change-Id in commit message, you did not copy the commit-hook. Make sure that the file .git/hooks/commit-msg exists and is executable.

Afterwards, you have to amend your commit to make it include the commit message:

git commit --amend

Push: prohibited by gerrit

If Gerrit rejects your push with

[remote rejected] master -> master (prohibited by gerrit)

you are likely trying to do a simple git push. However, as Gerrit prohibits directly pushing to the target branches, you have to use this lengthy command:

git push origin HEAD:refs/for/<release-branch>/<topic>

see also here.

Pushing old Patch Set again

You want to make an old Patch Set the current one. You cannot simply checkout Patch Set 1 and push it again, as it is refused with a "no new changes" error message.

Amend the commit using

git commit --amend

Even without modifying the Commit Message, it gets a new SHA. This commit can be pushed again.

Conflicts caused by Git Submodules (sysext)

notice - Note

TYPO3 CMS does not use submodules anymore since May 27, 2013.

Checking out old Change Review prompts to add unrelated submodules

When checking-out (or cherry-picking) some patchset from Gerrit to review, which was build before new submodules were added to the core, the Git status might show something like this:

# On branch master
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#       added by us:        typo3/sysext/dbal
#       added by us:        typo3/sysext/extbase
#       added by us:        typo3/sysext/fluid
#       added by us:        typo3/sysext/version
#       added by us:        typo3/sysext/workspaces

The solution is to just make the current staging area forget about these submodules again (since they are most probably unrelated to the change you are wanting to review):

git reset typo3/sysext/dbal typo3/sysext/extbase typo3/sysext/fluid typo3/sysext/version typo3/sysext/workspaces

Checkout fails with "error: Untracked working tree file ..."

error: Untracked working tree file 'typo3/sysext/dbal/ChangeLog' would be overwritten by merge

# force the checkout with -f parameter
$ git checkout -f <targetbranch>
# run git status to see the effected files
$ git status -s
 M typo3/sysext/dbal
 M typo3/sysext/version
 M typo3/sysext/workspaces
# now delete the directories
$ rm -rf typo3/sysext/{dbal,version,workspaces}
# reset current branch
$ git reset --hard
HEAD is now at <commit message of last commit>
# now pull again
$ git pull
Current branch <branch> is up to date.
# now update the submodule pointers
$ git submodule update --init

Submodules are poluting your commit

This is especially happening if you e.g. switch between master and TYPO3_4-5 branch.

# will show the differences
$ git submodule status
+96b4ce91b0c2645a498ed586a1c3630db4467462 typo3/sysext/dbal (issue_26779)
# call for an update
$ git submodule update
Submodule path 'typo3/sysext/dbal': checked out '2329d5ace7fbcbc81759b62abe052a189f810f47'
$ git submodule status
2329d5ace7fbcbc81759b62abe052a189f810f47 typo3/sysext/dbal (heads/master)

Unmerged paths

Cherry-picking an old commit fails with

error: could not apply 9e6c8ee... [BUGFIX]<title-of-the-commit>
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

git status then shows Unmerged paths and prompt displays (<branch> *+|CHERRY-PICKING)$

$ git status
# On branch 4-5
# Changes to be committed:
#	modified:   ....
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#	added by us:        typo3/sysext/extbase
#	added by us:        typo3/sysext/fluid

To resolve this state, reset these paths to HEAD and commit the result:

git checkout HEAD typo3/sysext/extbase
git checkout HEAD typo3/sysext/fluid
git commit

Don't forget to remove the Conflicts: section from the Commit Message.

An alternative to cherry-picking here is rebasing as described in Submit: Failing/Path conflict.

Submit problems

This section applies to team members only, when a patch passed the review process and should be merged into the official repository.

Failing / Path conflict

Gerrit Code Review

Your change could not be merged due to a path conflict.

Please merge (or rebase) the change locally and upload the resolution for review.

# (1) checkout patch as usual (copy & paste from gerrit!)
$ git fetch git://<path>/<project> refs/changes/<ZZ>/<XYZZ>/<A> && git checkout FETCH_HEAD
# (2) rebase onto the (meanwhile updated) <targetbranch> (master, TYPO3_4-5, ...)
$ git rebase origin/<targetbranch>
# (3) push again
$ git push origin HEAD:refs/for/<targetbranch>

Creating branches

New branches can be created most easily through Gerrit. If you are a project leader, you can create branches in Gerrit. Go to and log in. Then go to Projects > List > choose your project > Branches.

There you can create a new branch by providing a branch name and the SHA hash of the commit, which should be associated with the branch.

Recover from errors

This section is about recovering from errors if you have done the front action.

Recover from an accidental "git reset --hard"

If you already committed your changes, you will find the commit within

git reflog

Just create a new branch with

git branch recover-branch <commit>

It gets harder if you have not committed your changes. But in case you have already added your changes, you are in luck. Git has already created objects from your changes and you can recover all files you added. If not, than you should try to find the temp folder of your editor/IDE or you can try to recover something with the history function of your IDE.

To recover the added files, run

git fsck --lost-found

This will put all files (blobs) into .git/lost-found/others/. This folder contains all your files, but named after the hash of the blob. So you will have to open all files, check the content and copy them manually to the place they belong. Much better than redoing your patches, or?

To read more about recovery, read the Git Internals Section in the Git Book.