Fatal protocol error bad pack header

Ошибка fatal: The remote end hung up unexpectedly при выполнении git push

Иногда при работе с git через http возникает ошибка The remote end hung up unexpectedly . Это может обозначать одну из нескольких проблем. Одна из проблем — размер репозитория больше максимально допустимого размера будефа POST. Рассмотрим решение данной проблемы.

Вывод о данной ошибке выглядит примерно следующим образом:

Итак, первый вариант решения данной проблемы состоит в увеличении буфера данных POST запроса.

В первую очередь необхожимо узнать размер данных. В приведенном выше примере вывода размер равен 204.43 МБ. К этому числу добавим небольшой запас (например, до 250 МБ) и переведем все в байты. 250 МБ = 250 * 1024 * 1024 = 262144000 КБ. Задаем полученное значение в настройки git.

Этой командой мы выставили значение для конкретного репозитория, если необходимо применить данную настройку глобально, то необходимо добавить флаг —global:

Если ваш сервер для хранения git репозиториев имеет максимальный размер тела запроса меньше заданного размера, то необходимо перенастроить web-сервер (если есть такая возможность). Для этого необходимо изменить значение client_max_body_size (для nginx) или LimitRequestBody (для apache) и перезагрузить сервис ( service nginx reload или service apache2 reload соответственно). Если сервер не аш и нет возможности его сконфигурировать, то остается вариант номер 2.

Второй вариант заключается в переходе с протокола http на ssh. Вам будет необходимо изменить адрес удаленного репозитория с помощью команды git remote set-url :

Вот мы рассмотрели два пути решения ошибки The remote end hung up unexpectedly . Вероятно есть другие причины возникновения данной ошибки и иные пути решения. Эта статья не охватывает все возможные варианты, но надеюсь, что она вам помогла.

Источник

Name already in use

gitlabhq / doc / topics / git / troubleshooting_git.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

Copy raw contents

Copy raw contents

Troubleshooting Git (FREE)

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.

NOTE: Configuring both the client and the server is unnecessary.

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).

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.

Источник

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).

Источник

Git remote end hung up unexpectedly

I am trying to set up a git repo on my test server when I try to push from my windows computer

I get the error

But when I ssh’d into my server and tried to do the the exact same command it worked just fine. Is this a problem with my git setup or with my windows setup

2 Answers 2

The problem might be caused by a number of issues:

• Git is installed in some weird place on the server, and the environment that «git» user gets when being logged in interactively (you do this by hand via PuTTY or whatever) differs from the environment it gets when being logged in non-interactively (the git client does this for you). This is because Unix shells read different startup files in these cases, and when git uses SSH to spawn remote git instance it still spawns the default (for the user) shell on the server.
• You have a local problem (say, you configured Git to use plink.exe to access the server, and it asks you to accept the host’s key by entering «y» or «n» (which you can’t do).

In any case, try these steps:

Run plink.exe git@server.com «git —version» and see it’s able to run Git on the server at all. If you don’t use plink.exe use whatever binary is shipped with OpenSSH included with Git for Windows; probably it’s ssh.exe .

Export GIT_TRACE=1 before running git push and see if it prints out anything hinting at what went wrong, like this:

Источник

Ошибка fatal: The remote end hung up unexpectedly при выполнении git push

Иногда при работе с git через http возникает ошибка The remote end hung up unexpectedly . Это может обозначать одну из нескольких проблем. Одна из проблем — размер репозитория больше максимально допустимого размера будефа POST. Рассмотрим решение данной проблемы.

Вывод о данной ошибке выглядит примерно следующим образом:

Итак, первый вариант решения данной проблемы состоит в увеличении буфера данных POST запроса.

В первую очередь необхожимо узнать размер данных. В приведенном выше примере вывода размер равен 204.43 МБ. К этому числу добавим небольшой запас (например, до 250 МБ) и переведем все в байты. 250 МБ = 250 * 1024 * 1024 = 262144000 КБ. Задаем полученное значение в настройки git.

Этой командой мы выставили значение для конкретного репозитория, если необходимо применить данную настройку глобально, то необходимо добавить флаг —global:

Если ваш сервер для хранения git репозиториев имеет максимальный размер тела запроса меньше заданного размера, то необходимо перенастроить web-сервер (если есть такая возможность). Для этого необходимо изменить значение client_max_body_size (для nginx) или LimitRequestBody (для apache) и перезагрузить сервис ( service nginx reload или service apache2 reload соответственно). Если сервер не аш и нет возможности его сконфигурировать, то остается вариант номер 2.

Второй вариант заключается в переходе с протокола http на ssh. Вам будет необходимо изменить адрес удаленного репозитория с помощью команды git remote set-url :

Вот мы рассмотрели два пути решения ошибки The remote end hung up unexpectedly . Вероятно есть другие причины возникновения данной ошибки и иные пути решения. Эта статья не охватывает все возможные варианты, но надеюсь, что она вам помогла.

Источник

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).

Источник

Name already in use

gitlabhq / doc / topics / git / troubleshooting_git.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

Copy raw contents

Copy raw contents

Troubleshooting Git (FREE)

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.

NOTE: Configuring both the client and the server is unnecessary.

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).

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.

Источник

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

Community

Answers, support, and inspiration

Suggestions and bugs

Feature suggestions and bug reports

Marketplace

Billing and licensing

Frequently asked questions

Viewport

Confluence

Git Clone Fails — fatal: The remote end hung up unexpectedly. fatal: early EOF fatal: index-pack failed

Related content

Still need help?

The Atlassian Community is here for you.

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the server and data center platforms .

Problem

During a clone or fetch, Git fails with the following errors:

Example 1

Example 2

git clone fails after 1 GB

and in atlassian-bitbucket.log

Diagnosis

This behavior is usually related to an intermediary that is terminating the request. Removing the intermediary from the equation and checking if the import would work can speed up the troubleshooting process.

For that, temporarily disable any firewall or anti-virus software and attempt the clone again or make an exception rule in the firewall settings.

To turn on Git debug logging, before pushing using the command line, proceed like this 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:

Cause

Possible causes include:

Cause #1 git debug output has error: RPC failed; result=56, HTTP code = 200
Error code 56 indicates a curl receive error of CURLE_RECV_ERROR which means there was some issue that prevented the data from being received during the clone process. Typically this is caused by a network setting, firewall, VPN client, or anti-virus that is terminating the connection before all data has been transferred.

Cause #2 There is no error code and git debug log shows that Nginx is configured as reverse proxy. Git clone fails after 1 GB.
e.g.

Workaround

Workaround for Cause #1: Switch to using SSH to perform the clone.

Workaround for Cause #2: Bypass the proxy and clone. e.g. How do I bypass a proxy for bitbucket server

Resolution

• Resolution for Cause #1:
  Change the anti-virus settings, firewall settings, or VPN client so that they allow connections from Bitbucket Server and do not terminate them prematurely. The specific change that needs to be done will depend on the technology being used and sometimes it will be helpful to check the vendor documentation.
• Resolution for Cause #2:
  Disable the default 1GB limit of proxy_max_temp_file_size for Nginx. Value need to be set as zero to disable it
  You can find more details here http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size .

During a clone or fetch, Git fails with EOF errors.

Источник