git-upload-pack: nie znaleziono polecenia podczas klonowania zdalnego repozytorium Git

Używałem git do synchronizowania dwóch kopii mojego projektu, jedna to moje lokalne pudełko, a druga serwer testowy. Jest to problem, który pojawia się, gdy loguję się na nasz zdalny serwer programistyczny przy użyciu ssh;

git clone me@me.mydevbox.com:/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 'me@me.mydevbox.com:/home/chris/myproject' failed.

(nazwy plików zostały zmienione, aby chronić winnych ...!)

Oba komputery działają pod kontrolą systemu Solaris 10 AMD. Zrobiłem trochę kopania, jeśli dodam --upload-pack=$(which git-upload-pack)polecenie działa (i udowodni, że $PATHzawiera ścieżkę do `` git-upload-pack '' zgodnie z rozwiązaniem RTFM), ale jest to naprawdę denerwujące, a `` git push '' nie działa, ponieważ nie sądzę, że istnieje --unpack=opcja.

Nawiasem mówiąc, wszystkie polecenia git działają dobrze z mojego lokalnego pudełka, jest to ta sama wersja oprogramowania (1.5.4.2), zainstalowana na tym samym montowaniu NFS w /usr/local/bin.

Czy ktoś może pomóc?

Upewnij się, że git-upload-packznajduje się na ścieżce z powłoki niezalogowanej. (Na mojej maszynie jest w /usr/bin).

Aby zobaczyć, jak wygląda twoja ścieżka na komputerze zdalnym z powłoki bez logowania, spróbuj tego:

ssh you@remotemachine echo \$PATH

(Działa to w Bash, Zsh i tcsh, a prawdopodobnie także w innych powłokach).

Jeśli ścieżka, którą zwraca, nie zawiera katalogu, który ma git-upload-pack, musisz to naprawić, ustawiając go w .bashrc(dla Bash), .zshenv(dla Zsh), .cshrc(dla tcsh) lub równoważnym dla twojej powłoki.

Będziesz musiał wprowadzić tę zmianę na zdalnym komputerze.

Jeśli nie masz pewności, którą ścieżkę chcesz dodać do pilota PATH, możesz ją znaleźć za pomocą tego polecenia (musisz to uruchomić na zdalnym komputerze):

which git-upload-pack

Na mojej maszynie, która drukuje /usr/bin/git-upload-pack. W tym przypadku /usr/binjest to ścieżka, którą musisz się upewnić, że znajduje się w zdalnej powłoce bez logowania PATH.

Możesz także użyć opcji „-u”, aby określić ścieżkę. Uważam to za pomocne na maszynach, na których mój .bashrc nie jest pozyskiwany w sesjach nieinteraktywnych. Na przykład,

git clone -u /home/you/bin/git-upload-pack you@machine:code

Opierając się na odpowiedzi Briana , ścieżkę wysyłania pakietu można ustawić na stałe, uruchamiając następujące polecenia po klonowaniu, co eliminuje potrzebę --upload-packkolejnych żądań ściągania / pobierania. Podobnie ustawienie pakietu odbioru eliminuje potrzebę --receive-packwysyłania żądań.

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

Te dwa polecenia są równoważne dodaniu następujących wierszy do repozytorium .git/config.

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

Częstych użytkowników clone -umogą zainteresować następujące aliasy. myklon nie wymaga wyjaśnień. myfetch / mypull / mypush można używać w repozytoriach, których konfiguracja nie została zmodyfikowana, jak opisano powyżej, zastępując git pushją git mypushi tak dalej.

[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

Znalazłem i użyłem (pomyślnie) tej poprawki:

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

Dzięki Paulowi Johnstonowi .

Mac OS X i niektóre inne Uniksy mają przynajmniej skompilowaną ścieżkę użytkownika do sshd ze względów bezpieczeństwa, więc ci z nas, którzy instalują git jako / usr / local / git / {bin, lib, ...} mogą wpaść w kłopoty, ponieważ git Pliki wykonywalne nie znajdują się w prekompilowanej ścieżce. Aby to zmienić, wolę edytować zmiany w / etc / sshd_config:

#PermitUserEnvironment no

do

PermitUserEnvironment yes

a następnie utwórz pliki ~ / .ssh / środowiska według potrzeb. Moi użytkownicy git mają w swoim pliku ~ / .ssh / środowiska następujące informacje:

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

Uwaga: rozwijanie zmiennych nie występuje, gdy czytany jest plik ~ / .ssh / środowiska, więc:

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

nie będzie działać.

Rozwiązanie Matta nie działało dla mnie na OS X, ale Paul tak.

Krótka wersja z linku Pawła to:

Utworzono /usr/local/bin/ssh_sessionz następującym tekstem:

#!/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

Wykonać:

chmod +x /usr/local/bin/ssh_session

Dodaj następujące elementy do /etc/sshd_config:

ForceCommand / usr / local / bin / ssh_session

W przypadku basha należy go umieścić w .bashrc, a nie .bash_profile (.bash_profile jest również przeznaczony tylko dla powłok logowania).

Otrzymałem te błędy w wersji MsysGit.

Po wykonaniu wszystkich rad, które mogłem znaleźć tutaj i gdzie indziej, skończyłem:

instalowanie wersji Cygwin Git

na serwerze (Win XP z Cygwin SSHD), ostatecznie to naprawiło.

Nadal używam po stronie klienta wersji MsysGit

..w rzeczywistości jest to jedyny sposób, w jaki to działa dla mnie, ponieważ dostaję błędy POSIX podczas ściągania Cygwin Git z tego samego serwera sshd

Podejrzewam, że po tej stronie Gita nadal potrzeba trochę pracy. (Ssh + łatwość ściągania / wypychania w Windows)

Jak Johan wielokrotnie wskazywał, że potrzebny jest plik .bashrc:

ln -s .bash_profile .bashrc

Musisz dodać

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

przed tą linią w .bashrc:

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

W przeciwnym razie wszystkie wyciągi eksportowe nie zostaną wykonane ( patrz tutaj ).

Mój przypadek dotyczy Win 10 z GIT bash i nie mam GIT w standardowej lokalizacji. Zamiast tego mam git w / app / local / bin. Użyłem poleceń dostarczonych przez @Garrett, ale muszę zmienić ścieżkę, aby rozpocząć od double /:

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

W przeciwnym razie GIT doda twoją ścieżkę Windows GIT na początku.

W przypadku zsh musisz umieścić go w tym pliku: ~ / .zshenv

Na przykład w systemie OS X przy użyciu pakietu git-core z MacPorts:

$ echo 'export PATH = / opt / local / sbin: / opt / local / bin: $ PATH'> ~ / .zshenv

Miałem problemy z połączeniem się z repozytorium Gitolite za pomocą SSH z Windows i okazało się, że moim problemem był PLINK! Ciągle pytał mnie o hasło, ale ssh gitolite @ [host] zwróciłby listę repozytoriów w porządku.

Sprawdź zmienną środowiskową: GIT_SSH. Jeśli jest ustawiony na Plink, wypróbuj go bez żadnej wartości („set GIT_SSH =”) i zobacz, czy to działa.

Dodaj lokalizację swojego git-upload-packdo pliku .bashrc zdalnego użytkownika git.

Może to być tak proste, jak zainstalowanie gita na zdalnym hoście (tak jak to było w moim przypadku).

sudo apt-get install git

Lub odpowiednik dla innych systemów zarządzania pakietami.