Git push error code 22

https clone of gists fails (ssh works, see below):

12:00 jean@laptop:~/tmp$ GIT_CURL_VERBOSE=1 git clone https://gist.github.com/123456.git username
Initialized empty Git repository in /home/jean/tmp/username/.git/
* Couldn't find host gist.github.com in the .netrc file; using defaults
* About to connect() to gist.github.com port 443 (#0)
*   Trying 192.30.252.142... * Connected to gist.github.com (192.30.252.142) port 443 (#0)
* found 141 certificates in /etc/ssl/certs/ca-certificates.crt
*        server certificate verification OK
*        common name: *.github.com (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: C=US,ST=California,L=San Francisco,O=GitHub, Inc.,CN=*.github.com
*        start date: Mon, 30 Apr 2012 00:00:00 GMT
*        expire date: Wed, 09 Jul 2014 12:00:00 GMT
*        issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance CA-3
*        compression: NULL
*        cipher: ARCFOUR-128
*        MAC: SHA1
> GET /123456.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.7.1
Host: gist.github.com
Accept: */*
Pragma: no-cache

< HTTP/1.1 301 Moved Permanently
< Server: GitHub.com
< Date: Fri, 01 Nov 2013 05:00:51 GMT
< Content-Type: text/html
< Content-Length: 178
< Location: https://gist.github.com/gist/123456.git/info/refs?service=git-upload-pack
< Vary: Accept-Encoding
<
* Ignoring the response-body
* Expire cleared
* Connection #0 to host gist.github.com left intact
* Issue another request to this URL: 'https://gist.github.com/gist/123456.git/info/refs?service=git-upload-pack'
* Couldn't find host gist.github.com in the .netrc file; using defaults
* Re-using existing connection! (#0) with host gist.github.com
* Connected to gist.github.com (192.30.252.142) port 443 (#0)
> GET /gist/123456.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.7.1
Host: gist.github.com
Accept: */*
Pragma: no-cache

< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Fri, 01 Nov 2013 05:00:52 GMT
< Content-Type: application/x-git-upload-pack-advertisement
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
<
* Connection #0 to host gist.github.com left intact
* Couldn't find host gist.github.com in the .netrc file; using defaults
* About to connect() to gist.github.com port 443 (#0)
*   Trying 192.30.252.142... * connected
* Connected to gist.github.com (192.30.252.142) port 443 (#0)
* found 141 certificates in /etc/ssl/certs/ca-certificates.crt
* SSL re-using session ID
*        server certificate verification OK
*        common name: *.github.com (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: C=US,ST=California,L=San Francisco,O=GitHub, Inc.,CN=*.github.com
*        start date: Mon, 30 Apr 2012 00:00:00 GMT
*        expire date: Wed, 09 Jul 2014 12:00:00 GMT
*        issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance CA-3
*        compression: NULL
*        cipher: ARCFOUR-128
*        MAC: SHA1
> POST /123456.git/git-upload-pack HTTP/1.1
User-Agent: git/1.7.1
Host: gist.github.com
Accept-Encoding: deflate, gzip
Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Length: 116

< HTTP/1.1 301 Moved Permanently
< Server: GitHub.com
< Date: Fri, 01 Nov 2013 05:00:53 GMT
< Content-Type: text/html
< Content-Length: 178
< Location: https://gist.github.com/gist/123456.git/git-upload-pack
< Vary: Accept-Encoding
<
* Ignoring the response-body
* Connection #0 to host gist.github.com left intact
* Issue another request to this URL: 'https://gist.github.com/gist/123456.git/git-upload-pack'
* Violate RFC 2616/10.3.2 and switch from POST to GET
* Couldn't find host gist.github.com in the .netrc file; using defaults
* Re-using existing connection! (#0) with host gist.github.com
* Connected to gist.github.com (192.30.252.142) port 443 (#0)
> GET /gist/123456.git/git-upload-pack HTTP/1.1
User-Agent: git/1.7.1
Host: gist.github.com
Accept-Encoding: deflate, gzip
Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result

* The requested URL returned error: 400
* Closing connection #0
error: RPC failed; result=22, HTTP code = 400

This works: git clone git@gist.github.com:123456.git

git push fatal failed

I somehow deleted the whole directory of my code branch. I cloned a new one. It worked fine except pushing.

git pull works, though. How can I fix it?

8 Answers 8

I made the mistake of using https instead of ssh for a fresh copy. I since then made modifications and commits but could not push for obvious reasons.

To recover, I simple changed the section [remote «origin»] in .git/config from

After that, I could push again.

Faster HTTP Push with only git — webDAV is not required

The new «smart-http» support since git 1.6.6. The new method allows the entire pack to be transmitted at once, and not as individual files.

YOu can also use gitweb to provide browable URLs at the same location.

Note: Because access is controlled by apache you can add any Auth requirements (htaccess or ldap, etc) to the setup for each repository.

This answer assumes you own the remote server and want to add/fix http support.

FIRST: Check the apache logs, its likely a permission denied/unable to locate error when apache tries to execute the git-http-backed cgi scripts.

Adding HTTP Support to git

Just make a new git_support.conf file, and include it in apache (add include statement in httpd.conf)

The result is the ability to push/pull:

And you can browse those changes online..

Источник

error: RPC failed result=22 — Push to Stash fails

Troubleshooting Git

On this page

Related content

Still need help?

The Atlassian Community is here for you.

Symptoms

When pushing a large repository into Stash, the following outputs might appear after the git push:

Diagnosis

To turn on Git debug logging, before pushing using the command line, proceed like that for different OS:

On Linux

Execute the following in the command line before executing the Git command:

On Windows

Execute the following in the command line before executing the Git command:

Possible causes

When pushing a large amount of data (initial push of a big repository, change with very big file(s)) may require a higher http.postBuffer setting on your git client (not the server). From https://www.kernel.org/pub/software/scm/git/docs/git-config.html

Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system. For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally. Default is 1 MiB, which is sufficient for most requests.

Workaround

• Push the repository using SSH as this is an error related your HTTP(S) environment / set up.
• Bypass the proxy. Push directly to Stash IP:port.

Resolution

Increase the Git buffer size to the largest individual file size of your repo:

• git config —global http.postBuffer 157286400

Refer to the resolution of Git push fails — client intended to send too large chunked body for ngnix reverse proxy configuration. Increase this parameter to the largest individual file size of your repo.

Bypass the outbound proxy as explained on Can’t clone or pull due to a git outbound proxy

Источник

Bitbucket Support

Knowledge base

Products

Jira Software

Project and issue tracking

Jira Service Management

Service management and customer support

Jira Work Management

Manage any business project

Confluence

Bitbucket

Git code management

Resources

Documentation

Usage and admin help

Answers, support, and inspiration

Suggestions and bugs

Feature suggestions and bug reports

Marketplace

Billing and licensing

Frequently asked questions

Viewport

Confluence

error: RPC failed result=22 — Push to Bitbucket Server fails

Related content

Still need help?

The Atlassian Community is here for you.

Symptoms

When pushing a large repository into Bitbucket Server, the following outputs might appear after the git push:

Diagnosis

To turn on Git debug logging, before pushing using the command line, proceed like that for different OS:

On Linux

Execute the following in the command line before executing the Git command:

On Windows

Execute the following in the command line before executing the Git command:

Possible causes

When pushing a large amount of data (initial push of a big repository, change with very big file(s)) may require a higher http.postBuffer setting on your git client (not the server). From https://www.kernel.org/pub/software/scm/git/docs/git-config.html

Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system. For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally. Default is 1 MiB, which is sufficient for most requests.

Workaround

• Push the repository using SSH as this is an error related your HTTP(S) environment / set up.
• Bypass the proxy. Push directly to Bitbucket Server IP:port.

Resolution

Increase the Git buffer size to the largest individual file size of your repo:

• git config —global http.postBuffer 157286400

Refer to the resolution of Git push fails — client intended to send too large chunked body for ngnix reverse proxy configuration. Increase this parameter to the largest individual file size of your repo.

Bypass the outbound proxy as explained on Can’t clone or pull due to a git outbound proxy

Источник

Gitlab, почему то не вытягивается проект?

Добрый день, есть гитлаб сервер, там лежит один проект, заказчик уверяет что все права дал. Через веб морду удается создать ветку, добавить коммит, пушнуть это все.

User@User-pc MINGW64 /tmp/13
$ git clone gitlab.domen.ru/web/domen.git
Cloning into ‘domen’.
warning: You appear to have cloned an empty repository.

User@User-pc MINGW64 /tmp/13
$ cd domen/

User@User-pc MINGW64 /tmp/13/domen(master)
$ touch README.md

User@User-pc MINGW64 /tmp/13/domen(master)
$ git add README.md

User@User-pc MINGW64 /tmp/13/domen(master)
$ git commit -m «add README»
[master (root-commit) 9c69030] add README
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README.md

User@User-pc MINGW64 /tmp/13/domen(master)
$ git push -u origin master
error: Cannot access URL gitlab.domen.ru/web/domen.git/, return code 22
fatal: git-http-push failed
error: failed to push some refs to ‘gitlab.domen.ru/web/domen.git’

User@User-pc MINGW64 /tmp/13/domen(master)
$ git push origin master
error: Cannot access URL gitlab.domen.ru/web/domen.git/, return code 22
fatal: git-http-push failed
error: failed to push some refs to ‘gitlab.domen.ru/web/domen.git’

Так же пробовал и по другому
User@User-pc MINGW64 /tmp/13/1
$ git init
Initialized empty Git repository in C:/TEMP/13/1/.git/

User@User-pc MINGW64 /tmp/13/1 (master)
$ git remote add origin gitlab.domen.ru/web/domen.git

User@JurgenUserpc MINGW64 /tmp/13/1 (master)
$ git add .

User@User-pc MINGW64 /tmp/13/1 (master)
$ git commit -m «Initial commit»
On branch master

nothing to commit

User@User-pc MINGW64 /tmp/13/1 (master)
$ git push -u origin master
error: src refspec master does not match any.
error: failed to push some refs to ‘gitlab.domen.ru/web/domen.git’

Кто из нас тупит, я или тот кто мне дал доступ?

Источник

Troubleshooting Git

Sometimes things don’t work the way they should or as you might expect when you’re using Git. Here are some tips on troubleshooting and resolving issues with Git.

Broken pipe errors on git push

‘Broken pipe’ errors can occur when attempting to push to a remote repository. When pushing you usually see:

To fix this issue, here are some possible solutions.

Increase the POST buffer size in Git

If you’re using Git over HTTP instead of SSH, you can try increasing the POST buffer size in Git’s configuration.

Example of an error during a clone: fatal: pack has bad object at offset XXXXXXXXX: inflate returned -5

Open a terminal and enter:

The value is specified in bytes, so in the above case the buffer size has been set to 50MB. The default is 1MB.

Check your SSH configuration

If pushing over SSH, first check your SSH configuration as ‘Broken pipe’ errors can sometimes be caused by underlying issues with SSH (such as authentication). Make sure that SSH is correctly configured by following the instructions in the SSH troubleshooting documentation.

If you’re a GitLab administrator with server access, you can also prevent session timeouts by configuring SSH keep-alive on the client or the server.

To configure SSH on the client side:

/.ssh/config (create the file if it doesn’t exist) and add or edit:

On Windows, if you are using PuTTY, go to your session properties, then navigate to “Connection” and under “Sending of null packets to keep session active”, set Seconds between keepalives (0 to turn off) to 60 .

To configure SSH on the server side, edit /etc/ssh/sshd_config and add:

Running a git repack

If ‘pack-objects’ type errors are also being displayed, you can try to run a git repack before attempting to push to the remote repository again:

Upgrade your Git client

In case you’re running an older version of Git ( = 2.9 (see Broken pipe when pushing to Git repository).

ssh_exchange_identification error

Users may experience the following error when attempting to push or pull using Git over SSH:

This error usually indicates that SSH daemon’s MaxStartups value is throttling SSH connections. This setting specifies the maximum number of concurrent, unauthenticated connections to the SSH daemon. This affects users with proper authentication credentials (SSH keys) because every connection is ‘unauthenticated’ in the beginning. The default value is 10 .

Increase MaxStartups on the GitLab server by adding or modifying the value in /etc/ssh/sshd_config :

100:30:200 means up to 100 SSH sessions are allowed without restriction, after which 30% of connections are dropped until reaching an absolute maximum of 200.

After you modify the value of MaxStartups , check for any errors in the configuration.

If the configuration check runs without errors, it should be safe to restart the SSH daemon for the change to take effect.

Timeout during git push / git pull

If pulling/pushing from/to your repository ends up taking more than 50 seconds, a timeout is issued. It contains a log of the number of operations performed and their respective timings, like the example below:

This could be used to further investigate what operation is performing poorly and provide GitLab with more information on how to improve the service.

git clone over HTTP fails with transfer closed with outstanding read data remaining error

Sometimes, when cloning old or large repositories, the following error is thrown:

This is a common problem with Git itself, due to its inability to handle large files or large quantities of files. Git LFS was created to work around this problem; however, even it has limitations. It’s usually due to one of these reasons:

• The number of files in the repository.
• The number of revisions in the history.
• The existence of large files in the repository.

The root causes vary, so multiple potential solutions exist, and you may need to apply more than one:

If this error occurs when cloning a large repository, you can decrease the cloning depth to a value of 1 . For example:

You can increase the http.postBuffer value in your local Git configuration from the default 1 MB value to a value greater than the repository size. For example, if git clone fails when cloning a 500 MB repository, you should set http.postBuffer to 524288000 :

You can increase the http.postBuffer on the server side:

Modify the GitLab instance’s gitlab.rb file:

After applying this change, apply the configuration change:

For example, if a repository has a very long history and no large files, changing the depth should fix the problem. However, if a repository has very large files, even a depth of 1 may be too large, thus requiring the postBuffer change. If you increase your local postBuffer but the NGINX value on the backend is still too small, the error persists.

Modifying the server is not always an option, and introduces more potential risk. Attempt local changes first.

Password expired error on Git fetch via SSH for LDAP user

If git fetch returns this HTTP 403 Forbidden error on a self-managed instance of GitLab, the password expiration date ( users.password_expires_at ) for this user in the GitLab database is a date in the past:

Requests made with a SSO account and where password_expires_at is not null return this error:

To resolve this issue, you can update the password expiration by either:

Using the gitlab-rails console :

The bug was reported in this issue.

Error on Git fetch: “HTTP Basic: Access Denied”

If you receive an HTTP Basic: Access denied error when using Git over HTTP(S), refer to the two-factor authentication troubleshooting guide.

Help & feedback

Product

Feature availability and product trials

Get Help

If you didn’t find what you were looking for, search the docs.

If you want help with something specific and could use community support, post on the GitLab forum.

For problems setting up or using this feature (depending on your GitLab subscription).

Источник

Faster HTTP Push with only git — webDAV is not required

The new «smart-http» support since git 1.6.6. The new method allows the entire pack to be transmitted at once, and not as individual files.

YOu can also use gitweb to provide browable URLs at the same location.

Note: Because access is controlled by apache you can add any Auth requirements (htaccess or ldap, etc) to the setup for each repository.

This answer assumes you own the remote server and want to add/fix http support.

FIRST:
Check the apache logs, its likely a permission denied/unable to locate error when apache tries to execute the git-http-backed cgi scripts.

Adding HTTP Support to git

Just make a new git_support.conf file, and include it in apache (add include statement in httpd.conf)

#
#  Basic setup for git-http-backend
#

SetEnv GIT_PROJECT_ROOT /opt/git_repos
SetEnv GIT_HTTP_EXPORT_ALL
SetEnv REMOTE_USER=$REDIRECT_REMOTE_USER  #IMportant !!! This could be your problem if missing

<Directory /opt/git>  # both http_backend and gitweb should be somewhere under here
        AllowOverride None
        Options +ExecCGI -Includes  #Important! Lets apache execute the script!
        Order allow,deny
        Allow from all
</Directory>

# This pattern matches git operations and passes them to http-backend
ScriptAliasMatch 
        "(?x)^/git/(.*/(HEAD | 
                        info/refs | 
                        objects/(info/[^/]+ | 
                                 [0-9a-f]{2}/[0-9a-f]{38} | 
                                 pack/pack-[0-9a-f]{40}.(pack|idx)) | 
                        git-(upload|receive)-pack))$" 
        /opt/git/libexec/git-core/git-http-backend/$1

# Anything not matched above goes to displayable gitweb interface
ScriptAlias /git /opt/git/cgi-bin/gitweb.cgi/

The result is the ability to push/pull:

me@machine /tmp/eddies $ git pull
Already up-to-date.

me@machine /tmp/eddies $ touch changedFile

me@machine /tmp/eddies $ git add .

me@machine /tmp/eddies $ git commit -am"commiting change"
[master ca7f6ed] commiting change
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 changedFile

me@machine /tmp/eddies $ git push origin master
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 239 bytes, done.
Total 2 (delta 1), reused 0 (delta 0)
To http://mysecretdomain.com/git/eddies
   0f626a9..ca7f6ed  master -> master

And you can browse those changes online..

Source:
http://repo.or.cz/w/alt-git.git?a=blob_plain;f=gitweb/README

Symptoms

When pushing a large repository into Bitbucket Server, the following outputs might appear after the git push:

Counting objects: 9554, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (5064/5064), done.
Writing objects: 100% (9554/9554), 2.79 GiB | 694.00 KiB/s, done.
Total 9554 (delta 4382), reused 9554 (delta 4382)
error: RPC failed; result=22, HTTP code = 502
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
Everything up-to-date

POST git-receive-pack (33737128 bytes)

fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly

error: RPC failed; result=22, HTTP code = 413

Diagnosis

To turn on Git debug logging, before pushing using the command line, proceed like that for different OS:

On Linux

Execute the following in the command line before executing the Git command:

export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1

On Windows

Execute the following in the command line before executing the Git command:

set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1

Possible causes

• When pushing a large amount of data (initial push of a big repository, change with very big file(s)) may require a higher http.postBuffer setting on your git client (not the server). From https://www.kernel.org/pub/software/scm/git/docs/git-config.html

  http.postBuffer

  Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system. For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally. Default is 1 MiB, which is sufficient for most requests.

• Configuration on your reverse proxy. Usually ngnix the parameter client_max_body_size is a blocker. The reverse proxy may also have a connection timeout that’s closing the connection (e.g. TimeOut or ProxyTimeout in apache, proxy_read_timeout in ngnix). Try bypassing the proxy by pushing directly to Bitbucket Server IP:port. If this works, it’s highly likely that the proxy server is causing the early disconnect and needs to be tuned.
• User is using an outbound proxy on his machine that is causing the issue.
• Using an unsupported GIT version. Make sure the Bitbucket version being used is using a compatible GIT version. More info at Bitbucket Supported Platforms page.

Workaround

• Push the repository using SSH as this is an error related your HTTP(S) environment / set up.
• Bypass the proxy. Push directly to Bitbucket Server IP:port.

Resolution