git-upload-pack: Befehl nicht gefunden, wenn Remote-Git-Repo geklont wird


170

Ich habe git verwendet, um zwei Kopien meines Projekts synchron zu halten. Eine ist meine lokale Box, die andere der Testserver. Dies ist ein Problem, das auftritt, wenn ich mich mit ssh bei unserem Remote-Entwicklungsserver anmelde.

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.

(Die Dateinamen wurden geändert, um die Schuldigen zu schützen ...!)

Auf beiden Boxen wird Solaris 10 AMD ausgeführt. Ich habe ein bisschen gegraben, wenn ich hinzufüge, dass --upload-pack=$(which git-upload-pack)der Befehl funktioniert (und beweist, dass er $PATHden Pfad zu 'git-upload-pack' gemäß der RTFM-Lösung enthält), aber das ist wirklich ärgerlich, und 'git push' funktioniert nicht. weil ich glaube nicht, dass es eine --unpack=Option gibt.

Übrigens funktionieren alle Git-Befehle von meiner lokalen Box aus einwandfrei. Es handelt sich um dieselbe Version der Software (1.5.4.2), die auf demselben NFS-Mount unter installiert ist /usr/local/bin.

Kann jemand helfen?

Antworten:


169

Stellen Sie sicher, dass git-upload-packsich der Pfad von einer Nicht-Login-Shell befindet. (Auf meiner Maschine ist es in /usr/bin).

Versuchen Sie Folgendes, um zu sehen, wie Ihr Pfad auf dem Remotecomputer von einer Shell ohne Anmeldung aus aussieht:

ssh you@remotemachine echo \$PATH

(Das funktioniert in Bash, Zsh und tcsh und wahrscheinlich auch in anderen Shells.)

Wenn der zurückgegebene Pfad nicht das Verzeichnis enthält, das vorhanden ist git-upload-pack, müssen Sie ihn beheben, indem Sie ihn in .bashrc(für Bash), .zshenv(für Zsh), .cshrc(für tcsh) oder einem gleichwertigen Verzeichnis für Ihre Shell festlegen .

Sie müssen diese Änderung auf dem Remote-Computer vornehmen.

Wenn Sie nicht sicher sind, welchen Pfad Sie zu Ihrer Fernbedienung hinzufügen müssen PATH, können Sie ihn mit diesem Befehl finden (Sie müssen ihn auf der Fernbedienung ausführen):

which git-upload-pack

Auf meinem Computer, der druckt /usr/bin/git-upload-pack. In diesem Fall müssen /usr/binSie also sicherstellen , dass sich der Pfad in Ihrer Remote-Shell ohne Anmeldung befindet PATH.


2
Der Pfad war korrekt, wenn ich den Befehl auf meinem Computer ausführte, aber falsch, wenn ich ihn umgekehrt ausführte. (vom Remote-Computer zurück zu meinem) Durch Bearbeiten meiner lokalen .bashrc wurde das Problem behoben. Vielen Dank
Chris Huang-Leaver

6
Arbeitete an OSX Leopard
Noah Campbell

1
In meinem Fall wurde der Befehl nicht gefunden, da git über MacPorts installiert wurde, wodurch er eingefügt wird /opt/local/bin. Das Hinzufügen zu meinem .bashrcVia PATH=$PATH:/new/path/herehat für mich funktioniert.
Ben Scheirman

1
@ranReloaded Der Backslash soll dem Dollarzeichen entkommen und die Erweiterung von $ PATH auf dem lokalen Computer verhindern und stattdessen "echo $ PATH" buchstäblich an den Remote-Computer übergeben. Dies hängt möglicherweise davon ab, welche Shell Sie verwenden. es funktioniert für mich in zsh und bash. Möglicherweise können Sie das richtige Ergebnis mit einfachen Anführungszeichen erzielen, z. B. "ssh you @ remotemachine 'echo $ PATH'" - probieren Sie es aus. Welche Shell verwenden Sie sonst? Vielleicht verwendet jemand anderes hier diese Shell und kann Ihnen die Problemumgehung geben.
Matt Curtis

3
@ranReloaded: Wenn du sagst "der Git-Pfad wird nicht gedruckt", meinst du damit, dass ssh viele Dinge zeigt, aber nicht den Pfad, auf dem sich Git befindet? Wenn ja, dann haben Sie genau das gleiche Problem wie das OP, und die Verwendung eines Symlinks ist nur ein Pflaster. Der "ssh .. echo \$PATH" Befehl zeigt Ihnen den Pfad auf dem Remotecomputer an, der sich möglicherweise von Ihrem Anmeldepfad unterscheidet. Dies ist jedoch von entscheidender Bedeutung, damit er funktioniert, und Sie können dies tun, indem Sie PATH so einstellen, dass git in den .bashrcauf dem Computer aufgenommen wird Remote-Maschine. Laut Manpage werden .profile/ .bash_profilenur für interaktive Logins gelesen.
Matt Curtis

66

Sie können auch die Option "-u" verwenden, um den Pfad anzugeben. Ich finde dies hilfreich auf Computern, auf denen meine .bashrc-Datei nicht in nicht interaktiven Sitzungen bezogen wird. Beispielsweise,

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

2
Dank dafür. Ich wollte die ~ / .bashrc-Datei wirklich nicht ändern.
Luis

2
Nur zur Anmerkung: Hier finden Sie Anweisungen, wie Sie .bashrc für SSH-Sitzungen verwenden können.
sp3ctum

58

Aufbauend auf Brians Antwort kann der Upload-Pack-Pfad dauerhaft festgelegt werden, indem nach dem Klonen die folgenden Befehle ausgeführt werden, sodass --upload-packnachfolgende Pull / Fetch-Anforderungen nicht mehr erforderlich sind . In ähnlicher Weise entfällt durch das Einstellen des Empfangspakets die Notwendigkeit --receive-packvon Push-Anforderungen.

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

Diese beiden Befehle entsprechen dem Hinzufügen der folgenden Zeilen zu einem Repo .git/config.

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

Häufige Benutzer von clone -uinteressieren sich möglicherweise für die folgenden Aliase. myclone sollte selbsterklärend sein. myfetch / mypull / mypush kann für Repos verwendet werden, deren Konfiguration nicht wie oben beschrieben durch Ersetzen git pushdurch git mypushusw. geändert wurde .

[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

Vielen Dank für die Erwähnung der --receive-packOption zu git-push!
Axel

1
Vielen Dank, dass Sie die Konfigurationsoptionen erwähnt haben. Dies ist eine nützliche Anmerkung aus dem Benutzerbereich.
Aron Ahmadia

Ich habe Ihren Vorschlag ausprobiert und auch "welches Git-Receive-Pack" zum Pfad in .bashrc hinzugefügt, aber irgendwie funktioniert Git Push immer noch nicht für mich, obwohl das Hochladen von Repos gut funktioniert. Irgendeine Idee, warum das passieren könnte?
Coredump

@coredump Wenn Sie "remote.origin.receivepack" einstellen, müssen Sie PATH in Ihrem .bashrc nicht mehr ändern. Versuchen Sie git push --receive-pack /full/path/to/git-receive-packes selbst, optimieren Sie es, bis es erfolgreich ist, und ändern Sie dann .git / config (oder führen Sie "git config" aus), um den Pfad für das Empfangspaket dauerhaft festzulegen.
Garrett

Vielen Dank an alle für Ihre Antworten! In meinem Fall waren der Abrufserver und der Push-Server unterschiedlich und der Abrufserver hatte keine Schreibberechtigungen. Wenn ich git push <push-server> <branch> verwende, funktioniert alles einwandfrei.
Coredump

30

Ich habe dieses Update gefunden und (erfolgreich) verwendet:

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

Vielen Dank an Paul Johnston .


auch für mich behoben. Vielen Dank!
John Ballinger

12

Mac OS X und einige andere Unixe haben zumindest den Benutzerpfad aus Sicherheitsgründen in sshd kompiliert, sodass diejenigen von uns, die git als / usr / local / git / {bin, lib, ...} installieren, als git in Schwierigkeiten geraten können ausführbare Dateien befinden sich nicht im vorkompilierten Pfad. Um dies zu überschreiben, ziehe ich es vor, meine / etc / sshd_config-Änderung zu bearbeiten:

#PermitUserEnvironment no

zu

PermitUserEnvironment yes

und erstellen Sie dann nach Bedarf ~ / .ssh / Umgebungsdateien. Meine Git-Benutzer haben Folgendes in ihrer ~ / .ssh / Umgebungsdatei:

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

Beachten Sie, dass beim Lesen der Datei ~ / .ssh / environment keine Variablenerweiterung auftritt:

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

wird nicht funktionieren.


Dies scheint der perfekte Tipp zu sein, funktioniert aber hier für 10.6.6 nicht. ssh user @ host echo \ $ PATH zeigt weiterhin den fest codierten Erstellungspfad an. .Ssh / Umgebung mit nicht expandierendem erforderlichen Pfad hinzugefügt. Geändert / etc / sshd_config PermitUserEnvironment yes. kein Würfel. Irgendwelche Vorschläge? Vielen Dank.
Papa

Es wurde auch versucht, BASH_ENV = '~ / .nibashrc' auf dem Clientcomputer festzulegen und darin eine Datei mit dem erweiterten Pfad zu erstellen. auch keine Würfel.
Papa

OK. Das Einfügen des Pfads in .bashrc auf dem Computer, zu dem Sie eine Verbindung herstellen, hat für mich funktioniert.
Papa

Vielen Dank für den Tipp über variable Erweiterung funktioniert nicht für .ssh / Umgebung
Denis

Upvote für die Erklärung, dass die Var-Erweiterung funktioniert.
XMAN

7

Matts Lösung funktionierte unter OS X nicht für mich, Pauls jedoch.

Die Kurzversion von Pauls Link lautet:

Erstellt /usr/local/bin/ssh_sessionmit folgendem Text:

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

Ausführen:

chmod +x /usr/local/bin/ssh_session

Fügen Sie Folgendes hinzu /etc/sshd_config:

ForceCommand / usr / local / bin / ssh_session


Interessant zu hören, dass es bei Ihnen nicht funktioniert hat. Haben Sie etwas dagegen zu sagen, was PATH auf dem Remote-Computer lautete, als Sie "ssh you @ remote \ $ PATH" ausführten?
Matt Curtis

7

Für bash muss es in .bashrc und nicht in .bash_profile abgelegt werden (.bash_profile gilt auch nur für Login-Shells).


5

Ich habe diese Fehler mit der MsysGit-Version erhalten.

Nachdem ich alle Ratschläge befolgt hatte, die ich hier und anderswo finden konnte, endete ich:

Installation der Cygwin-Version von Git

Auf dem Server (Win XP mit Cygwin SSHD) wurde dies schließlich behoben.

Ich verwende immer noch die clientseitige MsysGit-Version

..in der Tat, es ist die einzige Möglichkeit, wie es für mich funktioniert, da ich POSIX-Fehler mit dem Cygwin Git Pull von demselben SSHD-Server bekomme

Ich vermute, dass auf dieser Seite der Git-Nutzung noch einige Arbeiten erforderlich sind. (SSH + einfaches Ziehen / Drücken in Windows)


1

Wie Johan oft darauf hingewiesen hat, dass .bashrc benötigt wird:

ln -s .bash_profile .bashrc


1

Sie müssen das hinzufügen

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

vor dieser Zeile in der .bashrc:

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

Andernfalls werden nicht alle Exportanweisungen ausgeführt ( siehe hier ).


1

Mein Fall ist auf Win 10 mit GIT-Bash und ich habe kein GIT unter Standardstandort. Stattdessen habe ich Git unter / app / local / bin. Ich habe die von @Garrett bereitgestellten Befehle verwendet, muss aber den Pfad ändern, um mit double / zu beginnen:

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

Andernfalls fügt die GIT Ihren Windows-GIT-Pfad vor.


0

Für zsh müssen Sie es in diese Datei einfügen: ~ / .zshenv

Beispiel: Unter OS X mit dem Git-Core-Paket von MacPorts:

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


0

Ich hatte Probleme beim Herstellen einer Verbindung zu einem Gitolite-Repo mit SSH unter Windows und es stellte sich heraus, dass mein Problem PLINK war! Es fragte mich immer wieder nach einem Passwort, aber der ssh gitolite @ [host] würde die Repo-Liste in Ordnung zurückgeben.

Überprüfen Sie Ihre Umgebungsvariable: GIT_SSH. Wenn es auf Plink eingestellt ist, versuchen Sie es ohne Wert ("set GIT_SSH =") und prüfen Sie, ob dies funktioniert.


0

Fügen Sie den Speicherort Ihrer git-upload-packDatei zur .bashrc-Datei des Remote-Git-Benutzers hinzu.


0

Es kann so einfach sein, wie git auf dem Remote-Host zu installieren (wie in meinem Fall).

sudo apt-get install git

Oder gleichwertig für andere Paketverwaltungssysteme.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.