git index.lock Datei existiert, wenn ich versuche, sie festzuschreiben, kann sie aber nicht löschen


196

Wenn ich 'git commit' mache, erhalte ich Folgendes:

fatal: Unable to create 'project_path/.git/index.lock': File exists.

Wenn ich das tue, heißt ls project_path/.git/index.lockes jedoch, dass die Datei nicht existiert. Irgendwelche Gedanken darüber, was ich tun soll? Ich habe auch festgestellt, dass project_path / .git root gehört. Ich bin mir nicht sicher, ob dies etwas mit dem Problem zu tun hat, auf das ich stoße.

Git-Version ist 1.7.5.4

Bearbeiten: Es scheint, dass das Problem höchstwahrscheinlich ein anderer Prozess war, den ich ausgeführt habe und der (ohne mein Wissen) in das Projektverzeichnis geschrieben hat. Ich habe meinen Computer neu gestartet und hatte dann kein Problem beim Festschreiben.


3
Es könnte durchaus ein Berechtigungsproblem sein, bei dem Git davon ausgeht, dass die bereits vorhandene Datei nicht erstellt werden kann. Haben Sie versucht, das Verzeichnis zu übernehmen oder Ihren Befehl mit sudo auszuführen?

1
Ich denke, deine Erklärung zu einer anderen App, die auf das Git-Repo zugreift, ist richtig. Hatte das gleiche Problem während einer Rebase. Gitx lief. Sobald ich aufgehört habe, hat es gut funktioniert.
The Who

2
@asahi: Möchtest du vielleicht eine Antwort akzeptieren? Dies wird zukünftigen Lesern helfen.
MERose


3
@asahi: Sie können den Inhalt Ihrer Bearbeitung (die die Lösung war) als Antwort veröffentlichen und diese dann akzeptieren. (Obwohl die allgemeinere Lösung als "Neustart der Maschine" darin besteht, dass ein anderer Prozess auf das Verzeichnis zugegriffen hat; ein Neustart schneidet nur den gordischen Knoten ab, um herauszufinden, welche und warum. :) In meinem Fall war es meine IDE.) Wie auch immer, Menschen beantworten häufig ihre eigenen Fragen, wenn sie ihre eigenen Lösungen finden, was Sie auch getan haben.
Wilson F

Antworten:


326

Dies mag eine alte Antwort sein, aber ich hoffe, dass dies für die nächsten, die diese Lösung benötigen, nützlicher ist.

Versuchen Sie es unter Linux / Unix / Gitbash / Cygwin

rm -f .git/index.lock

Versuchen Sie an der Windows-Eingabeaufforderung Folgendes:

del .git\index.lock


1
Ich sehe, dass manchmal die Sperrdatei automatisch gelöscht wird. Gibt es einen Hinweis, warum diese Datei manchmal manuell gelöscht werden muss?
Nrj

Ich habe kein index.lock, was tun? :(
Alex C

56
Angesichts der Tatsache, dass das Problem in der Frage darin bestand, dass er die Datei nicht löschen konnte, warum sollte Ihrer Meinung nach der Versuch, die Datei zu löschen, die Lösung sein?
Skyking

4
Für mich hat das Schließen und Öffnen von SourceTree das Problem gelöst ... Vorübergehend, nehme ich an.
Andrew

1
@skyking in der ursprünglichen Frage gibt es einen Fehler, der besagt fatal: Unable to create 'project_path/.git/index.lock': File exists., dass "Datei existiert", und das Löschen wäre eine einfache Lösung. Warum sollte ich vorschlagen, eine Datei zu löschen, wenn sie nicht einmal in der ursprünglichen Frage enthalten ist?
Ryan S

40

Für Windows:

  • Versuchen Sie es mit einer als Administrator geöffneten Powershell-Konsole
> rm -Force ./.git/index.lock
  • Wenn dies nicht funktioniert, müssen Sie alle git.exe-Prozesse beenden
> taskkill /F /IM git.exe
SUCCESS: The process "git.exe" with PID 20448 has been terminated.
SUCCESS: The process "git.exe" with PID 11312 has been terminated.
SUCCESS: The process "git.exe" with PID 23868 has been terminated.
SUCCESS: The process "git.exe" with PID 27496 has been terminated.
SUCCESS: The process "git.exe" with PID 33480 has been terminated.
SUCCESS: The process "git.exe" with PID 28036 has been terminated.
> rm -Force ./.git/index.lock

1
Parameter können nicht verarbeitet werden, da der Parametername 'f' nicht eindeutig ist.
3pitt

danke, @MikePalmice, ich habe auf -Force aktualisiert. Scheint, als hätten sie die API geändert
Andrei Epure

20

Auf einer Windows-Plattform, auf der Visual Studio 2015 RC (v4.6.00057) in Kombination mit SourceTree (v1.6.14.0) ausgeführt wird, wird dieser Fehler ebenfalls angezeigt.

Lösung: Angenommen, Sie möchten den Quellbaum als Quellcode-Manager verwenden, deaktivieren Sie einfach den Versionsverwaltungsanbieter in Visual Studio wie folgt:

  1. Gehen Sie zu: Extras> Optionen> Quellcodeverwaltung
  2. Wählen Sie das Plug-In für die aktuelle Quellcodeverwaltung wie folgt aus: Keine

Obwohl mein VS nicht einmal auf diese Repositorys zugreifen soll, war dies ohnehin das Problem beim erneuten Basieren mit SourceTree.
Kajetan Abt

Vielen Dank, Problem ist immer noch mit Update 3.
Elger Mensonides

Das Schließen von Visual Studio funktioniert auch (die Datei index.lock wurde gelöscht.)
misterbee

10
  1. Überprüfen Sie, ob der Git noch läuft (ps -ef | grep git)
  2. Wenn nicht, entfernen Sie die gesperrte Datei
  3. Wenn ja, beenden Sie zuerst den Git-Prozess.

9

Versuchen

rm -f ./.git/index.lock

Wenn kein anderer Git-Prozess ausgeführt wird, löschen Sie einfach die Datei index.lock des jeweiligen Projekts.


Arbeitete an der Umgebung meines Mac.
Adam Hurwitz

6

Hatte gerade dieses Problem ... Gitbox war schuld. Vielleicht lief eine GUI, die Probleme verursachte.


Es war keine GUI, aber ich hatte einen separaten Prozess, der in das Projektverzeichnis schrieb. Ich konnte es nicht herausfinden und es machte mich verrückt.
Asahi

Es sieht so aus, als würde GitX auch dieses Problem verursachen.
Glutexo

6 Jahre später war es Atom für mich
Milch

6

Dies geschieht, wenn Sie das Ziehen vom Ursprung in der Mitte abbrechen.

Sie können also die Datei index.lock manuell aus Ihrem .git-Verzeichnis löschen.

rm -f ./.git/index.lock

CD in Ihr Projektverzeichnis und führen Sie diesen Befehl aus.


8
Angesichts der Tatsache, dass das Problem in der Frage darin bestand, dass er die Datei nicht löschen konnte, warum sollte Ihrer Meinung nach der Versuch, die Datei zu löschen, die Lösung sein?
Skyking

+1 @skyking. Das Löschen einer Datei ist offensichtlich. Das Problem besteht darin, dass keine Datei gelöscht werden muss und das Problem weiterhin besteht.
Catsunami

6
  1. Schließen Sie jedes Fenster, das möglicherweise Auswirkungen auf diese .git / index.lock-Datei hat
  2. Löschen Sie die Datei .git / index.lock.
  3. Öffnen Sie Ihren Befehlszeileneditor und die CD an den Speicherort Ihrer Git-Dateien.

(Wenn die Datei einfach von CD an diesen Speicherort erstellt wird, liegt das Problem bei Ihrem Editor. Schließen Sie Ihren Editor. Verwenden Sie diesen Editor für diese Aufgabe nicht erneut. Öffnen Sie eine andere Art von Editor - Windows Power Shell oder einfach cmd. Jetzt Sie können Git-Befehle verwenden, um fortzufahren.


5

Wahrscheinlich (es ist mir passiert) sagt der Befehl ls, dass er nicht existiert, weil der aktuelle Benutzer keine Berechtigung hat, dieses Verzeichnis oder diese Datei zu erreichen.

Entfernen Sie die Sperre und stellen Sie sicher, dass Sie git mit dem richtigen Benutzer ausführen, um Berechtigungsprobleme zu vermeiden.

Wenn Sie sich in einer GNU / Linux-Box mit dem Befehl sudo befinden :

sudo rm project_path / .git / index.lock


In Windows können Sie mit Rechtsklick-> Eigenschaften-> Attribute überprüfen, ob der Ordner schreibgeschützt ist.
Matt

Angesichts der Tatsache, dass das Problem in der Frage darin bestand, dass die Datei nicht vorhanden war, warum sollte Ihrer Meinung nach der Versuch, die Datei zu löschen, die Lösung sein?
Skyking

@skyking Berechtigungsprobleme zeigen den gleichen Fehler. In der Tat bin ich auf diese Frage gekommen, weil der Titel. Ich schrieb meine Antwort als eine mögliche Lösung und einige Stimmen bestätigen, dass sie auch anderen Menschen
einfällt

@caligari Nicht genau. Das Berechtigungsproblem gibt eine andere Antwort auf ls project_path/.git/index.lock.
Skyking

5

del .git\index.lock arbeitete für mich.

Ich war mit diesem Problem konfrontiert, als ich einen neuen Zweig vom Hauptzweig auscheckte.

Das Auschecken erfolgte leicht nach dem Löschen der index.lockDatei.


4

Manchmal erstellt Git eine Sperrdatei, die Ihrem Repo zugeordnet ist, während Sie Änderungen vornehmen oder höchstwahrscheinlich, wenn Sie Submodule verwenden. Die Fehlermeldung zeigt Ihnen den Pfad der Sperrdatei. Fix: Gehen Sie einfach manuell zum Pfad im Terminal und löschen Sie die Sperrdatei mit $ rm index.lock

Es sollte helfen.


4

Ich hatte dieses Problem mit SourceTree beim Wechseln des Zweigs durch Doppelklick darauf. Das Problem ist nicht sehr häufig und Atlassian weiß davon aber sie haben beschlossen, es nicht zu beheben.

Zum Glück gibt es eine Lösung. Anstatt auf den Zweig zu doppelklicken, den Sie wechseln möchten, klicken Sie einfach mit der rechten Maustaste und wählen Sie "Kasse [Name des Zweigs]". Es sollte jetzt gelingen.


danke, Rechtsklick> Kasse funktioniert als Alternative. Die Fehlermeldung ist ziemlich irreführend, insbesondere wenn index.lock nicht vorhanden ist.
Ernest

4

Ich bin auf das gleiche Szenario gestoßen. Ich habe noch keine Änderungen an meinem lokalen Code vorgenommen. Ich habe gerade eine Datei bearbeitet und zurückgesetzt. Ich habe einfach die folgende Datei im versteckten .git-Ordner gelöscht. Es funktionierte!

project_path / .git / index.lock


3

Sofern Sie nicht beabsichtigt haben, dass root Ihr Repo besitzt, klingt dies so, als hätten Sie versehentlich einen Git-Befehl als root ausgeführt (möglicherweise sogar den ersten Klon / Init). Wenn du das vorhast, musst du damit leben, alle Git-Befehle im Repo als root auszuführen. Wenn Sie dies nicht getan haben, rennen Sie los, um die Verantwortung dafür sudo chown your-user[:your-group] -R .gitzu übernehmen, und prüfen Sie dann, ob die Dinge funktionieren.


In meinem Fall hatte ich den Modus der Dateien und Verzeichnisse durcheinander gebracht .gitund sie korrigiert mit: find .git -type f -exec chmod 644 {} \;und find .git -type d -exec chmod 755 {} \;ich hatte auch die Modi durcheinander gebracht, als ich mein Git-Projekt von einem Computer auf den anderen
verschoben hatte

In meinem Fall habe ich sudo chmod g+w .git -R
Beatriz Fonseca

2

Mehrere Git-Clients, die an demselben lokalen Repository arbeiten, konkurrieren um diese Sperre. Jeder Kunde sollte warten, bis die Sperre von der anderen Partei freigegeben wird, um ein guter Bürger zu sein. Für uns scheinen SourceTree oder MSVS im Hintergrund einige Wartungsarbeiten durchzuführen, während wir große Festschreibungsskripte ausführen.

Vielleicht sollte 'git' selbst ein '--retriesWhenLocked 5'-Argument unterstützen, um Wiederholungsversuche zu unterstützen.oder sogar standardmäßig, wenn manuell ausgeführt.

Hier ist ein PowerShell-Wrapper um git mit dem Namen "gitr", der erneut versucht, bis index.lock verschwindet. Dabei werden standardmäßig 5 Versuche mit jeweils 3 Sekunden Abstand verwendet. Die index.lock wird niemals entfernt, vorausgesetzt, der Benutzer sollte eingreifen. Es wurde aus einem größeren Commit-Skript extrahiert. Es gibt nur minimale Tests mit einfachen Argumenten.

  • Kopieren Sie das Skript nach C: \ bin und fügen Sie C: \ bin zu $ ​​PATH hinzu.
  • Von PS1> gitr --help
  • Von DOS%> Powershell Gitr - Hilfe

gitr.ps1

    #requires -version 2
    <#
    .SYNOPSIS
        gitr
    .DESCRIPTION
        Run "git" as an external process with retry and capturing stdout stderr.
    .NOTES  
      2017/05/16 crokusek: Initial version
    #>

    #---------------------------------------------------------[Initializations]--------------------------------------------------------

    #Set Error Action 
    $ErrorActionPreference = "Stop";

    #----------------------------------------------------------[Declarations]----------------------------------------------------------

    $scriptDir = Split-Path $script:MyInvocation.MyCommand.Path
    #Set-Location $scriptDir

    ## Disabled logging
    # Log File 
    # $logFile = "$($scriptDir)\getr.log"
    # If (Test-Path $logFile) { Clear-Content $logFile }

    #-----------------------------------------------------------[Functions]------------------------------------------------------------

    Function Log([string]$msg, [bool]$echo = $true)
    {
        $timestamp = "$(get-date -Format 'yyyy/MM/dd HH:mm:ss'):  " 
        $fullmsg = $msg -replace '(?ms)^', $timestamp  # the (?ms) enables multiline mode

        ## Disabled Logging 
        # Add-content $LogFile -value $fullmsg

        if ($echo)
        {
            Write-Host $msg
        }
    }

    Function ExecSimple([string]$command, [bool]$echo=$true, [bool]$stopOnNonZeroExitCode=$true)
    {
        $command, $args = $command -split " "
        return Exec $command $args $echo $stopOnNonZeroExitCode
    }

    Function Exec([string]$exe, [string[]]$arguments, [bool]$echo=$true, [bool]$stopOnNonZeroExitCode=$true)
    {   
        # Passing $args (list) as a single parameter is the most flexible, it supports spaces and double quotes

        $orgErrorActionPreference = $ErrorActionPreference 
        Try
        {           
            $error.clear()  # this apparently catches all the stderr pipe lines

            if ($false -and $exe -eq 'git')  # todo make this a generic flag
            {
                $exe = "$($exe) 2>&1"
            }

            $output = ""

            $argflattened = $arguments -join ' '
            Log "`n% $($exe) $($arguments)`n"

            # This way some advantages over Invoke-Expressions or Start-Process for some cases:
            #      - merges stdout/stderr line by line properly, 
            #      - echoes the output live as it is streamed to the current window,
            #      - waits for completion
            #      - works when calling both console and windows executables.
            #       
            $ErrorActionPreference = "Continue"  # required in order to catch more than 1 stderr line in the exception

            if ($echo)
            {
                # Using "cmd.exe" allows the stderr -> stdout redirection to work properly.  Otherwise the 2>&1 runs after PS for 
                # some reason.  When a command such as "git" writes to stderr, powershell was terminating on the first stderr 
                # line (and stops capturing additional lines).
                #
                # but unfortuantely cmd has some bizarre de-quoting rules that weren't working for all cases. 
                #& cmd /c "`"" $exe $arguments "`"" | Tee-Object -variable output | Write-Host | out-null           

                # This is simplest but has some issues with stderr/stdout (stderr caught as exception below)
                #
                & $exe $arguments 2>&1 | tee -variable output | Write-Host | out-null 
            }
            else
            {           
                & $exe $arguments 2>&1 | tee -variable output | out-null 
            }

            $output = $output -join "`r`n"                  

            if ($stopOnNonZeroExitCode -and !$LASTEXITCODE -eq 0)
            {           
                throw [System.Exception] "Exit code ($($LASTEXITCODE)) was non-zero. Output:`n$($output)"
            }       
        }
        catch [System.Management.Automation.RemoteException]
        {
            $output = $_.Exception.ToString().Replace("System.Management.Automation.RemoteException:", "").Trim()

            if ($output.Contains("fatal")) 
            {
                throw 
            }

            if ($echo)
            {
                Log $output
            }
        }
        finally
        {
            $ErrorActionPreference = $orgErrorActionPreference;
        }

        if (-not $output -eq "")
        {
            Log $output $false  # don't echo to screen as the pipe above did    
        }

        return $output
    }

    Function ExecWithRetry([string]$exe, [string[]]$arguments, [bool]$echo=$true, [bool]$stopOnNonZeroExitCode=$true, 
                          [int]$maxRetries = 5, [int]$msDelay = 3000, [AllowNull()][string]$exceptionMustContain = $null)
    {
        for ($i = 0; $i -lt $maxRetries; $i++)
        {
            try
            {
                Exec $exe $arguments $echo $stopOnNonZeroExitCode
                return
            }
            catch
            {
                if (-not [string]::IsNullOrEmpty($exceptionMustContain) -and $_.Exception.ToString().Contains($exceptionMustContain))
                {
                    Log "Last Error from $($exe) is retryable ($($i + 1) of $($maxRetries))" $true
                    Start-Sleep -Milliseconds ($msDelay);
                    continue
                }

                throw
            }
        }

        throw [System.Exception] "Unable to successfully exec '$($exe)' within $($maxRetries) attempts."
    }

    Function GitWithRetry([string[]]$arguments, [bool]$echo=$true)
    {
        ExecWithRetry "git" $arguments $echo -exceptionMustContain "Another git process seems to be running"
    }

#-----------------------------------------------------------[Main]------------------------------------------------------------

function Main([string[]]$arguments)
{   
    GitWithRetry @($arguments)
}


#-------------------------------------- Startup ------------------------------------
try 
{
    Main $args
    Exit 0
}    
catch
{
    #Log "*** A fatal error occured: $($_.Exception)"
    #Read-Host -Prompt "`nA fatal error occurred, press enter to close."    
    exit 1
}

2

Ich habe diese Frage auch in Windows 10.

wenn ich del versuche ./.git/index.lock, sagte es mircannot remove 'index.lock': Device or resource busy

Ich habe endlich den Grund bekommen:

Der Computer hat zwei Prozesse, um Git zu verwenden:

  • Git Bash
  • cmder

Also benutze ich cmder.exe, um git commitFehler zu verursachen.

Die Lösung lautet also "Verwenden" git bashoder "Beenden" git bashund verwenden Sie "cmder.exe"


1

Ich hatte genau den gleichen Fehler, aber das Problem war nicht die Sperrdatei. Stattdessen bestand das Problem darin, dass ich den Inhalt eines anderen Git-Repos in dieses Repo kopiert hatte, einschließlich des unsichtbaren Ordners .git. Daher war SourceTree verwirrt darüber, für welches Repo ich Dateien bereitstellen wollte (es gab eine Nichtübereinstimmung zwischen dem Repo, in dem SourceTree sich befand, und dem, in dem der Inhalt meines eingebetteten .git-Verzeichnisses angegeben war, dass ich mich befinden sollte).


1

Ich hatte dieses Problem mit TortoiseGit mit Cygwin unter Windows. Ich konnte remove ./.git/index.lock selbst mit Administratorrechten nicht löschen. Ich habe sowohl Cygwin als auch die Eingabeaufforderung ausprobiert. Die Datei wurde von einem anderen Prozess verwendet.

Ich habe festgestellt, dass 2 Instanzen von TortoiseProc.exe ausgeführt wurden. Ich habe einen von ihnen getötet, alle meine Windows Explorer-Fenster geschlossen und konnte dann die Datei löschen. Ich weiß nicht, ob das Beenden einer Instanz von TortoiseProc.exe die Lösung oder das Schließen von Windows Explorer-Fenstern war.


1

Die Lösung für mich war, die .index-Datei zu löschen und Git zu erlauben, eine andere neu zu erstellen.


1

Ich hatte keine unst.lock-Datei zum Löschen, aber was für mich funktionierte, war das Entfernen der schreibgeschützten Prüfung aus dem Fenster Attribute des Dialogfelds Eigenschaften des Ordners.


1

Ich habe eine leere index.lock-Datei erstellt und sie mit dem Windows-Befehl gelöscht



1

In meiner sourceTree-Anwendung kann ich kein Commit durchführen oder zu einem anderen Commit / Brach wechseln. Diese Zeit zeigt Fehler wie

tödlich: Kann nicht bla bla bla erstellen ..

Ich löse dies einfach durch den Ordner goto .git (im Projekt Explorer Dir). Und löschen Sie den Index ----- [Dateityp: LOCK-Datei]. Jetzt bekomme ich alle Zugriff in sourceTree zurück ..

Stellen Sie sicher, dass die Indexsperrdatei vorhanden ist. Angenommen, Sie erhalten keinen Dateityp. Ändern Sie die Einstellungen für die Dateiansicht auf dem Computer. Hinweis: Der Ordner .git ist normalerweise ein versteckter Ordnertyp.


1

Was es für mich getan hat war:

git rebase --abort und starten Sie die Rebase neu.

Wie Andrew erwähnte, habe ich auch PHPStorm verwendet, als dies passierte. Musste es aber nicht schließen.


1

Zuerst müssen Sie zu dem bestimmten Ordner Ihres Projekts navigieren. Wenn Ihr Projektname Firstproject lautet, gehen Sie zuerst in das Verzeichnis des Projekts. Geben Sie dann cd .git ein und geben Sie nach dem Navigieren zum git-Ordner del index.lock After ein das Löschen der Datei index.lock..Sie können wie zuvor festschreiben und pushen


1

In meinem Fall waren es Fenster, die nicht vollständig heruntergefahren wurden.

Windows befindet sich im Ruhezustand und kann nicht gemountet werden

Es besteht die Möglichkeit, dass Windows wirklich in den Ruhezustand versetzt wird. Windows tut dies automatisch, wenn Sie es anweisen, normal herunterzufahren. Der Vorteil ist, dass Sie eine schnellere scheinbare Startzeit erhalten.

Geben Sie an einer Eingabeaufforderung (unter Windows) Folgendes aus, um Windows ohne Hybernierung herunterzufahren:

shutdown /s

Möglicherweise möchten Sie auch /t 0zum sofortigen Herunterfahren einschließen .

Ich habe ein nettes Tutorial gefunden, um einen Launcher dafür einzurichten: So führen Sie ein vollständiges Herunterfahren in Windows 8 durch, ohne den Hybridstart zu deaktivieren.

Der einfachere Ansatz zum tatsächlichen Herunterfahren von Windows besteht darin, "neu zu starten" (anstatt "herunterzufahren"), dann aber den Startvorgang abzufangen und Linux zu starten, anstatt Windows starten zu lassen.

Kredit : Nobar


1

Dies kann auch passieren, wenn Sie einen alternativen Befehlszeilen-Git-Client wie Hub verwenden .

Ich benutze Hub seit ein paar Jahren als Alias-Ersatz für Git, habe aber kürzlich ein Bash-Skript geschrieben, das eine Menge Git-Arbeit darin leistet, und habe angefangen, dieses Problem mit der Indexsperre zu bekommen.

Ich konnte das Update nicht finden, bis ich mich daran erinnerte, dass ich Hub anstelle von Git ausführte. Ich habe das entfernt und das Problem ging weg!


0

Fehler erhalten:

Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
fatal: Unable to create '/home/user/project/.git/index.lock': File exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.

Aber ich konnte diese .git / index.lock-Datei nicht finden (oder löschen).

In meinem Fall lief Git-Cola!

Es wird offensichtlich von Zeit zu Zeit diese .git / index.lock erstellt oder durch die Rebase verursacht, die ich in der Befehlszeile ausgeführt habe und während der ich diesen Fehler erhalten habe - also "stört" git-cola offensichtlich den Befehlszeilenlauf von Git (oder einige Git CLI-Operationen).

Dies wird gelöst, indem git-cola während einer Befehlszeilen-git-Rebase geschlossen wird.


0

Manchmal kann ein anderer Git-Client stören, wenn mehrere installiert sind.

Dh. Stellen Sie sicher, dass mit dem Task-Manager oder Get-Processdem TGitCachevon TortoiseGit nicht im Hintergrund aktiv ist.


0

Ich hatte vor kurzem das gleiche Problem. Wenn Sie die gesamte Fehlermeldung überprüfen, heißt es auch, dass es einige Prozesse gibt, die den Git-Prozess verwenden, der Sie daran hindert, index.lock zu löschen. Möglicherweise ist eine IDE wie Visual Studio oder eine verwandte Software geöffnet, in die git integriert ist. Schließen Sie es und versuchen Sie, Ihre Datei erneut zu speichern. Ich hoffe es hilft.

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.