Git receive pack not found windows

I’ve tried many things before creating this topic. Since, many seem to have this problem. So here’s the thing. I simply can’t push to git-hub. I know what you might be thinking, that I haven’t added the bin directory to my PATH. But, I have, so before you mark this as a duplicate, please consider that I’ve looked at these:

http://stackoverflow.com/questions/12186040/git-receive-pack-stops-with-0000
http://stackoverflow.com/questions/225291/git-upload-pack-command-not-found-how-to-fix-this-correctly
http://stackoverflow.com/questions/15323268/git-upload-pack-not-found
http://stackoverflow.com/questions/15777797/git-push-error-git-receive-pack
http://stackoverflow.com/questions/1483722/git-receive-pack-command-not-found-in-windows

I’ve even downloaded the github for windows app, and it still gives me the same error. So, what do you do, when you get this error, on a windows machine, I’, running Git 1.8.1. This is the error:

https://github.com/random12345@gmail.com/random.git/info/refs?service=git-receive-pack not found: did you run git update-server-info on the server?

EDIT 1:
Not showing my real email, I’m just showing you the gist of the message.

When you run git push the send-pack part of the protocol is running on your, local side, and it connects to the receive-pack part running on the remote side.

So let’s say you run git push, where your remote origin repo is configured to use ssh and is mapped to server.com. Git uses send-pack to initiate a connection over ssh to the server extracted from the remote URL ^*:

$ ssh server.com "git-receive-pack /path/to/repo.git"

_{^* When the repository was previously cloned or added as git remote add origin ssh://server.com/path/to/repo.git}

Note that the quoted command is run by ssh on the remote server, and it is possible that git-receive-pack could not be located there. You can test for this yourself as follows:

$ ssh server.com "type -p git-receive-pack" || echo "git-receive-pack not found"

If indeed the git-receive-pack command could not be located on the remote — for instance, because it is not in the PATH of your remote login shell, you can tell git push where it should look for it by running:

$ git push --receive-pack=/server/com/full/path/to/git-receive-pack

And you can save typing that every time you push by telling git to remember to use the explicit path via the config:

$ git config remote.origin.receivepack /server/explicit/path/to/git-receive-pack

HTTPS cloning errors

There are a few common errors when using HTTPS with Git. These errors usually indicate you have an old version of Git, or you don’t have access to the repository.

Here’s an example of an HTTPS error you might receive:

> error: The requested URL returned error: 401 while accessing
> https://github.com/USER/REPO.git/info/refs?service=git-receive-pack
> fatal: HTTP request failed

> Error: The requested URL returned error: 403 while accessing
> https://github.com/USER/REPO.git/info/refs
> fatal: HTTP request failed

> Error: https://github.com/USER/REPO.git/info/refs not found: did you run git
> update-server-info on the server?

Check your Git version

There’s no minimum Git version necessary to interact with GitHub, but we’ve found version 1.7.10 to be a comfortable stable version that’s available on many platforms. You can always download the latest version on the Git website.

Ensure the remote is correct

The repository you’re trying to fetch must exist on GitHub.com, and the URL is case-sensitive.

You can find the URL of the local repository by opening the command line and
typing git remote -v:

$ git remote -v
# View existing remotes
> origin  https://github.com/ghost/reactivecocoa.git (fetch)
> origin  https://github.com/ghost/reactivecocoa.git (push)

$ git remote set-url origin https://github.com/ghost/ReactiveCocoa.git
# Change the 'origin' remote's URL

$ git remote -v
# Verify new remote URL
> origin  https://github.com/ghost/ReactiveCocoa.git (fetch)
> origin  https://github.com/ghost/ReactiveCocoa.git (push)

Alternatively, you can change the URL through our
GitHub Desktop application.

Provide an access token

To access GitHub, you must authenticate with a personal access token instead of your password. For more information, see «Creating a personal access token.»

If you are accessing an organization that uses SAML SSO and you are using a personal access token (classic), you must also authorize your personal access token to access the organization before you authenticate. For more information, see «About authentication with SAML single sign-on» and «Authorizing a personal access token for use with SAML single sign-on.»

Check your permissions

When prompted for a username and password, make sure you use an account that has access to the repository.

Tip: If you don’t want to enter your credentials every time you interact with the remote repository, you can turn on credential caching. If you are already using credential caching, please make sure that your computer has the correct credentials cached. Incorrect or out of date credentials will cause authentication to fail.

Use SSH instead

If you’ve previously set up SSH keys, you can use the SSH clone URL instead of HTTPS. For more information, see «About remote repositories.»

Error: Repository not found

If you see this error when cloning a repository, it means that the repository does not exist or you do not have permission to access it. There are a few solutions to this error, depending on the cause.

Check your spelling

Typos happen, and repository names are case-sensitive. If you try to clone git@github.com:user/repo.git, but the repository is really named User/Repo you will receive this error.

To avoid this error, when cloning, always copy and paste the clone URL from the repository’s page. For more information, see «Cloning a repository.»

To update the remote on an existing repository, see «Managing remote repositories».

Checking your permissions

If you are trying to clone a private repository but do not have permission to view the repository, you will receive this error.

Make sure that you have access to the repository in one of these ways:

• The owner of the repository
• A collaborator on the repository
• A member of a team that has access to the repository (if the repository belongs to an organization)

Check your SSH access

In rare circumstances, you may not have the proper SSH access to a repository.

You should ensure that the SSH key you are using is attached to your personal account on GitHub. You can check this by typing
the following into the command line:

$ ssh -T git@github.com
> Hi USERNAME! You've successfully authenticated, but GitHub does not
> provide shell access.

If the repository belongs to an organization and you’re using an SSH key generated by an OAuth App, OAuth App access may have been restricted by an organization owner. For more information, see «About OAuth App access restrictions.»

For more information, see Adding a new SSH key to your GitHub account.

Check that the repository really exists

If all else fails, make sure that the repository really exists on GitHub.com!
If you’re trying to push to a repository that doesn’t exist, you’ll get this error.

Error: Remote HEAD refers to nonexistent ref, unable to checkout

This error occurs if the default branch of a repository has been deleted on GitHub.com.

Detecting this error is simple; Git will warn you when you try to clone the repository:

$ git clone https://github.com/USER/REPO.git
# Clone a repo
> Cloning into 'repo'...
> remote: Counting objects: 66179, done.
> remote: Compressing objects: 100% (15587/15587), done.
> remote: Total 66179 (delta 46985), reused 65596 (delta 46402)
> Receiving objects: 100% (66179/66179), 51.66 MiB | 667 KiB/s, done.
> Resolving deltas: 100% (46985/46985), done.
> warning: remote HEAD refers to nonexistent ref, unable to checkout.

To fix the error, you’ll need to be an administrator of the repository on GitHub.com.
You’ll want to change the default branch of the repository.

After that, you can get a list of all the available branches from the command line:

$ git branch -a
# Lists ALL the branches
>   remotes/origin/awesome
>   remotes/origin/more-work
>   remotes/origin/new-main

Then, you can just switch to your new branch:

$ git checkout new-main
# Create and checkout a tracking branch
> Branch new-main set up to track remote branch new-main from origin.
> Switched to a new branch 'new-main'

git clone [email protected]:/home/chris/myproject
Initialized empty Git repository in /tmp/myproject/.git/
Password:
bash: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly
fetch-pack from '[email protected]:/home/chris/myproject' failed.

15 Answers

ssh [email protected] echo $PATH

git clone -u /home/you/bin/git-upload-pack [email protected]:code

git config remote.origin.uploadpack /path/to/git-upload-pack
git config remote.origin.receivepack /path/to/git-receive-pack

[remote "origin"]
    uploadpack = /path/to/git-upload-pack
    receivepack = /path/to/git-receive-pack

[alias]
    myclone = clone --upload-pack /path/to/git-upload-pack
    myfetch = fetch --upload-pack /path/to/git-upload-pack
    mypull  = pull --upload-pack /path/to/git-upload-pack
    mypush  = push --receive-pack /path/to/git-receive-pack

# Fix it with symlinks in /usr/bin
$ cd /usr/bin/
$ sudo ln -s /[path/to/git]/bin/git* .

#PermitUserEnvironment no

PermitUserEnvironment yes

PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin

PATH=$PATH:/usr/local/git/bin

#!/bin/bash
export SSH_SESSION=1
if [ -z "$SSH_ORIGINAL_COMMAND" ] ; then
    export SSH_LOGIN=1
    exec login -fp "$USER"
else
    export SSH_LOGIN=
    [ -r /etc/profile ] && source /etc/profile
    [ -r ~/.profile ] && source ~/.profile
    eval exec "$SSH_ORIGINAL_COMMAND"
fi

export PATH=/opt/git/bin:$PATH

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

git config remote.origin.uploadpack //path/to/git-upload-pack
git config remote.origin.receivepack //path/to/git-receive-pack

sudo apt-get install git

При попытке отредактировать этот старый пост слетело всё форматирование. Может быть я его когда-нибудь исправлю.

Я потратил несколько месяцев на борьбу с глюками Git-svn и обдумывание разных вариантов, прежде чем пришёл к этому методу организации рабочего процесса с сайтом — простому, гибкому и удобному в работе.

Основные преимущества:

• Делая push из удалённой копии мы автоматически обновляем live-копию сайта
• Правки файлов на сервере не будут разрушать историю коммитов
• Простота, не нужны особые правила выполнения коммитов
• Можно применить к уже запущенному сайту, без повторного деплоя или перемещения файлов

Обзор

Главная идея системы — создение на сервере двух репозиториев: пустого bare-репозитория и обычного репозитория с рабочей копией сайта. Эта пара связана парой простых хуков, которые автоматизируют push и pull изменений.

Итак, два репозитория:

• Hub — bare-репозиторий. Все репозитории разработчиков клонируются именно от него.
• Prime — обычный репозиторий. Сайт запускается из рабочего каталога этого репозитория.

Работа с двумя репозиториями простая и очень гибкая. Удалённые копии, имеющие ssh-доступ могут легко обновлять live-версию сайта просто выполнив push в Hub-репозиторий. Любые изменения, выполненные в live-версии на сервере мгновенно вливаются в Hub при коммите. В общем, всё работает очень просто — и неважно, где делаются изменения.

Небольшие приготовления перед стартом

Естественно, в первую очередь нужно, что бы Git был установлен на сервере и на всех компах разработчиков. Если на вашем shared-хостинге не установлен Git — вы очень легко можете это исправить (en).

Если вы первый раз работаете с Git на своём сервере, не забудьте указать глобальные настройки. Я указываю особое значения для user.name, чтобы потом видеть в истории проекта изменения, выполненные на сервере:

$ git config --global user.name "Джо, фигачу на сервере"


Поехали!

В первую очередь создадим новый git-репозиторий в live-каталоге нашего сайта, а затем добавим и зафиксируем все файлы сайта. Это будет Prime-репозиторий и рабочая копия. Даже если уже есть история проекта в других местах, содержимое сайта будет базовой точкой, в которую потом будут слиты все остальные копии.

$ cd ~/www
$ git init
$ git add .
$ git commit -m "Импорт всех существующих файлов сайта"


Поскольку мы сделали инициализацию репозитория в рабочей копии – нет нужды отключать сайт на обслуживание и повторно выкладывать все файлы, Git просто содаст репозиторий из имеющихся файлов.

Теперь, когда наш сайт уже находится в Git, создадим bare-репозиторий где-нибудь вне рабочего каталога сайта.

$ cd
$ mkdir site_hub.git
$ cd site_hub.git
$ git --bare init
Initialized empty Git repository in /home/joe/site_hub.git

Ура! Снова вернёмся в рабочий каталог сайта и добавим Hub как удалённый репозиторий, а затем вольём в Hub содержимое ветки master из Prime-репозитория.

$ cd ~/www
$ git remote add hub ~/site_hub.git
$ git remote show hub
* remote hub
 URL: /home/joe/site_hub.git
$ git push hub master

Хуки

Как я уже упоминал в начале, Hub и Prime синхронизируются между собой, используя два простых скрипта.

Одно из основных правил при работе с Git — никогда не делайте push в репозтирий, у которого есть рабочая копия. Мы следуем этому правилу и создали репозиторий «Hub». Вместо того, чтобы делать push из Hub, который никак не повлияет на рабочую копию, мы будем использовать хук, который заставит Prime выполнить pull из Hub-репозитория.

Post-update — в Hub-репозитории

Как только в Hub поступит новая порция изменений, сразу будет выполнен этот скрипт. Мы переходим в рабочий каталог Prime-репозитория, и вытягиваем измениния из Hub’а. Проталкивание изменений (push) не изменяет состояния рабочего каталога репозитория, поэтому и нужно делать pull, находясь в рабочем каталоге.

#!/bin/sh

echo
echo

"**** Вытягиваем изменения в Prime [Hub's post-update hook]"
echo

cd $HOME/www || exit
unset GIT_DIR
git pull hub master

exec git update-server-info

Post-commit — в Prime-репозитори

Этот скрипт запускается после каждого коммита в Prime-репозитории и проталкивает изменения в Hub. В идеальном мире, конечно, мы вообще никогда ничего не будем править прямо на сервере. Но в нашем несовершенном мире возможно всё, что угодно, поэтому давайте автоматизируем процесс проталкивания изменений, чтобы не разрушать историю проекта и избежать возможных конфликтов.

#!/bin/sh

echo
echo

"**** pushing changes to Hub [Prime's post-commit hook]"
echo

git push hub

Итак, используя этот хук, мы сразу же получаем в Hub-репозитория все изменения, выполненные в master-ветке Prime-резпозитория. Прочие ветки также можно клонировать, но они не будут влиять на сайт. Поскольку все удалённые копии получают доступ через SSH-адрес к Hub, то выполнить push и запустить обновление сайта напрямую могут только пользователи, имеющие прямой доступ к shell’у.

Конфликты

«Положить» сайт при такой системе синхронизации двух репозиториев очень сложно. Каждое изменение, сделанное в Prime автоматически попадает в Hub и все конфликты будут сразу видны при попытке выполнить push из клонов репозитория.

Но всё же есть несколько ситуаций, при которых состояние Prime может отличаться от Hub’а, и для исправления ситуации потребуется выполнить несколько дополнительных телодвижений. Если мы что-то правим на Prime и не зафиксировали изменения, а в этот момент сработает post-update в Hub, то все завершится ошибкой с сообщением «Entry ‘foo’ not uptodate. Cannot merge.». Фиксация изменений в рабочем каталоге Prime позволит зачистить его состояние, и post-update хук сможет соединить все неотправленные изменения.

Также я обнаружил, что если конфликт возникает вследствие того, что изменения в Prime не могут быть объединены с Hub’ом, то наилучшим решением будет протолкнуть текущее состояние Prime’а в новую ветку на Hub. Эта команда, выполненная из рабочего каталога Prime создаст удалённую ветку «fixme», основанную на текущем стоянии Prime-репозитория.

$ git push hub master:refs/heads/fixme

Как только изменения окажутся в Hub’е, мы сможем получить ветку в любом из клонов, разрешить конфликт и смержить ветки. Попытка разрешить конфликт прямо на сервере почти наверняка приведёт к проблемам в работе сайте из-за появления маркеров конфликтных областей.

Держим всё в чистоте

Каталог .git Prime-репозитория находится в корневом каталоге сайта, и, верояно, доступен для публичного доступа. Чтобы никто не смог сунуть свой нос, куда не следует, добавьте эти строки в файл .htaccess верхнего уровня:

# deny access to the top-level git repository:
RewriteEngine On
RewriteRule .git - [F,L]

Прим. переводчика: есть и другие способы закрыть доступ к каталогу на сервере.

Прочие проблемы

Если при попытке выполнить push в репозиторий на сервере вы видите эту ошибку:

git-receive-pack: command not found
fatal: The remote end hung up unexpectedly


В этом случае просто добавьте export PATH=${PATH}:~/bin в ваш файл .bashrc, лежащий на сервере.

Skip to content

Recently we planned to use git version control system. So I tried to setup the git server in the server machine, and everything went  well from the server side. While making local copy in the the local machine we got the below error.