3. git: fatal: 'z:\git_root\myproject' does not appear to be a git repository

git: fatal: 'z:\git_root\myproject' does not appear to be a git repository


  • Hallo zusammen,

    habe hier ein seltsames Problem. Ich habe eine Windows-Netzwerkfreigabe auf Z:\ gemounted und darin liegen einige git-Repositories. Für die einfache Bedienung benutze ich Tortoise Git und mache fast alles aus dem Kontextmenü des Windows Explorers. Klappt auch alles wunderbar, nur habe ich mir jetzt überlegt, ein kleines Tool zu bauen, und darüber commits und pushes zu machen. Hat den Vorteil, dass die Release Info und Tags halbautomatisch erzeugt werden können (bestimmt das Tool für mich). Der commit in´s lokale Repository klappt (e:\tmp\myproject), der push in das remote Repository allerdings nicht. git quittiert das mit der Fehlermeldung 'fatal: z:\git_root\myproject' does not appear to be a git repository.

    Kommandozeile für CreateProcess-Aufruf (commit) und Ausgabe:

    "c:\programme\git\bin\git.exe" -C "e:\tmp\myproject" commit --all --signoff --untracked-files=no --status --quiet --message="..."

Ausgabe:
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit

    Kommandozeile für CreateProcess-Aufruf (push) und Ausgabe:

    "c:\programme\git\bin\git.exe" -C "e:\tmp\myproject" push origin master

Ausgabe:
fatal: 'Z:\git_root\myproject' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

    Kommandozeile für CreateProcess-Aufruf (remote) und Ausgabe:

    "c:\programme\git\bin\git.exe" -C "e:\tmp\myproject" remote -v

Ausgabe:
origin Z:\git_root\myproject(fetch)
origin Z:\git_root\myproject(push)

    Wenn ich die Kommandozeile aus dem CreateProcess-Aufruf in der Kommandozeile einer DOS-Box ausführe klappt auch der push. Bin grad etwas ratlos. Installiert ist git V2.18.0.windows.1 und die config Dateien der Repositories sehen so aus:

    Inhalt der lokalen config Datei (e:\tmp\myproject\.git\config):

    [core]
   repositoryformatversion = 0
   filemode = false
   bare = false
   logallrefupdates = true
   symlinks = false
   ignorecase = true
   hideDotFiles = dotGitOnly
[remote "origin"]
   url = Z:\\git_root\\myproject
   fetch = +refs/heads/*:refs/remotes/origin/*
   puttykeyfile = ""
[branch "master"]
   remote = origin
   merge = refs/heads/master

    Inhalt der origin config Datei (z:\git_root\myproject\config):

    [core]
   bare = true
   repositoryformatversion = 0
   filemode = false
   symlinks = false
   ignorecase = true

    Hat da jemand ´ne Idee?

    0 1 Antwort

  • Naja, ist z:\git_root\myproject denn ein Git Repo? Also stimmt der Pfad und das alles? Passen die Berechtigungen für den User mit dem du das probierst?

    1

  • Wow, Hustbär, danke für den Hinweis. Es lag tatsächlich am Benutzer, wobei ich mir das jetzt wieder nicht erklären kann.
    Die IDE läuft als elevated process unter meinem Benutzerkonto und startet das git-Tool, das damit dann auch als elevated Prozess läuft. Hab das gerade mal mit zwei DOS-Boxen ausprobiert:

    1. normale DOS-Box: Laufwerk Z:\ ist gemounted und der Zugriff auf´s Repo klappt, Benutzerkonto ist mein Windows-Benutzer
    2. DOS-Box als Administrator: Laufwerk Z:\ ist nicht gemounted, Benutzerkonto ist mein Windows-Benutzer

    Im Task Manager wird für beide cmd.exe mein Benutzerkonto als Besitzer angezeigt. Ich benutze den Process Hacker und der zeigt mir für beide Prozesse den gleichen Benutzernamen und SID an. Nur dass der ein Prozess elevated ist und kein Z:\ hat und der andere ist nicht-elevated und hat ein Laufwerk Z:\.
    Mal sehen, vielleicht finde ich was dazu im Netz.

    Edit:
    Microsoftt Artikel dazu

    0

  • OK. Workaround ist aber einfach: UNC Pfade für die Remotes verwenden. (Und für alles andere was das Zeug was in dem Skript läuft auf dem Z Laufwerk braucht.)

    Oder, Alternativ: Mach ne Junction bzw. nen Symlink auf das Netzlaufwerk. Siehe https://superuser.com/questions/244562/how-do-i-mount-a-network-drive-to-a-folder
    Die Junction/den Symlink gibt's dann auch unabhängig von Benutzerkonto/Session.

    1

  • Hab das jetzt über den EnableLinkedConnections Eintrag in der Registry gemacht.
    Nochmal Danke für den Hinweise mit mklink, das ist sicher noch mal nützlich.

    0
Anmelden zum Antworten