git index.lock İşlem yapmaya çalıştığımda dosya var, ancak dosyayı silemiyorum


197

'Git taahhüdü' yaptığımda aşağıdakileri alıyorum:

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

Ancak bunu yaptığımda ls project_path/.git/index.lockdosyanın mevcut olmadığını söylüyor. Ne yapmam gerektiğine dair düşüncelerin var mı? Ayrıca project_path / .git köküne ait olduğunu fark ettim, karşılaştığım sorunla ilgili bir şey olup olmadığından emin değilim.

git sürümü 1.7.5.4

edit: Görünüşe göre sorun büyük olasılıkla çalıştığım başka bir süreç, proje dizinine (bana bilinmeyen) yazma oldu. Makinemi yeniden başlattım ve sonra hiçbir sorun yaşamadım.


3
Git'in dosyayı oluşturamadığı için zaten var olduğunu varsaydığı bir izin sorunu olabilir. Dizinin sahipliğini almayı veya komutunuzu sudo kullanarak çalıştırmayı denediniz mi?

1
Git deposuna erişen başka bir uygulama hakkındaki açıklamanızın doğru olduğunu düşünüyorum. Rebase sırasında da aynı problem vardı. Gitx koşuyordu. Bir kez bıraktım git iyi çalıştı.
Kim

2
@asahi: Belki bir cevabı kabul etmek istiyor musun? Bu, gelecekteki okuyuculara yardımcı olacaktır.
MERose


3
@asahi: Düzenlemenizin içeriğini (çözüm olan) bir yanıt olarak gönderebilir ve daha sonra kabul edebilirsiniz. ('Makineyi yeniden başlatmaktan' daha genel bir çözüm, dizine başka bir işlemin erişmesidir; yeniden başlatma, Gordian düğümünü hangisinin ve nedenini anlamaya çalışmaktan keser. :) Benim durumumda, IDE'mdi.) Her neyse, insanlar kendi çözümlerini bulduklarında sık sık kendi sorularını cevaplıyorlar, ki bu da sizin yaptığınız.
Wilson F

Yanıtlar:


330

Bu eski bir yanıt olabilir, ancak bunun bu çözüme ihtiyacı olan bir sonraki kişide daha yararlı olacağını umuyorum.

Linux / unix / gitbash / cygwin'de deneyin

rm -f .git/index.lock

Windows Komut İstemi'nde şunları deneyin:

del .git\index.lock


1
Bazen kilit dosyasının otomatik olarak silindiğini görüyorum. Bu dosyanın neden bazen manuel olarak silinmesi gerektiğine dair herhangi bir ipucu var mı?
Nrj

Bir index.lock'um yok, ne var? :(
Alex C

56
Sorudaki sorunun dosyayı silememesi nedeniyle, dosyayı silmeye çalışmanın neden çözüm olduğunu düşünüyorsunuz?
6'da skyking

4
SourceTree'yi kapatıp açmak benim için sorunu çözdü ... Sanırım geçici olarak.
Andrew

1
@ orijinal soru sorulduğunda bir hata var fatal: Unable to create 'project_path/.git/index.lock': File exists., "Dosya var" diyor ve bunu silmek basit bir çözüm olacaktır. Orijinal soruda olmasa bile bir dosyayı silmeyi neden öneririm?
Ryan S

40

Pencereler için:

  • Yönetici olarak açılan bir powershell konsolundan şunu deneyin:
> rm -Force ./.git/index.lock
  • Bu işe yaramazsa, tüm git.exe işlemlerini öldürmelisiniz
> 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
'F' parametre adı belirsiz olduğundan parametre işlenemiyor.
3pitt

teşekkürler, @MikePalmice, -Force'a güncelledim. Görünüşe göre API'yı değiştirdiler
Andrei Epure

20

Visual Studio 2015 RC'yi (v4.6.00057) SourceTree (v1.6.14.0) ile birlikte çalıştıran bir Windows platformunda da bu hata oluşacaktır.

Çözüm: Kaynak ağacını kaynak kodu yöneticisi olarak kullanmak istediğinizi varsayarsak, Visual Studio içindeki kaynak denetim sağlayıcısını şu şekilde devre dışı bırakmanız yeterlidir:

  1. Araçlar> Seçenekler> Kaynak Kontrolü'ne gidin.
  2. Geçerli kaynak kontrolü eklentisini şu şekilde seçin: Yok

VS'm bu depolara bile erişmesi gerekmese de, SourceTree ile yeniden basarken sorun yine de buydu.
Kajetan Abt

Teşekkür ederim, sorun Güncelleme 3 ile hala orada.
Elger Mensonides

Visual Studio'nun kapatılması da çalışıyor (index.lock dosyasını sildi.)
misterbee

10
  1. git'in hala çalışıp çalışmadığını kontrol et (ps -ef | grep git)
  2. değilse, kilitli dosyayı kaldırın
  3. evet ise, önce git işlemini öldürün.

9

Deneyin

rm -f ./.git/index.lock

çalışan başka bir git işleminiz yoksa, ilgili projenin index.lock dosyasını silin.


Mac'imin ortamında çalıştım.
Adam Hurwitz

6

Sadece bu sorunu yaşadım ... Gitbox hatalıydı. Belki de sorun yaratan bir GUI çalıştırabilirsiniz.


GUI değildi ama proje dizinine yazılan ayrı bir süreç vardı. Ben çözemedim ve bu beni deli ediyordu.
asahi

GitX bu soruna neden olmayı seviyor gibi görünüyor.
Glutexo

6 yıl sonra benim için Atom oldu
Milk

6

Bu, ortasından başlangıç ​​noktasından çekmeyi iptal ettiğinizde oluyor.

böylece index.lock dosyasını .git dizininizden elle silebilirsiniz.

rm -f ./.git/index.lock

proje dizinine cd ve bu komutu çalıştırın.


8
Sorudaki sorunun dosyayı silememesi nedeniyle, dosyayı silmeye çalışmanın neden çözüm olduğunu düşünüyorsunuz?
16'da

+1 @skyking. Bir dosyayı silmek açıktır, sorun silinecek dosya olmaması ve sorun devam etmesidir.
Catsunami

6
  1. Bu .git / index.lock dosyasını etkileyebilecek tüm pencereleri kapatın
  2. .Git / index.lock dosyasını silin.
  3. Komut satırı düzenleyicinizi ve cd'nizi git dosyalarınızın konumuna açın.

(Dosya oluşturulduysa, sadece cd'den o konuma, o zaman sorun editörünüzdür. Düzenleyicinizi kapatın. Bu düzenleyici için bu editörü tekrar kullanmayın. Farklı bir düzenleyici - windows power shell veya sadece cmd açın. devam etmek için git komutlarını kullanabilirsiniz)


5

Muhtemelen (bu başıma gelen), ls komutu söylediğini o yok geçerli kullanıcının o dizini veya dosyayı ulaşmak için gerekli izinlere sahip olmadığı için.

Kilidi çıkarın ve izin sorunlarını önlemek için git'i doğru kullanıcıyla yürüttüğünüzden emin olun .

Sudo komutuyla bir GNU / Linux kutusundaysanız :

sudo rm proje_yolu / .git / index.lock


Windows'da, sağ tıklama-> Özellikler-> Öznitelikler ile klasörün salt okunur olup olmadığını kontrol edebilirsiniz.
Matt

Sorudaki sorunun dosyanın mevcut olmadığı göz önüne alındığında, neden dosyayı silmeye çalışmanın çözüm olduğunu düşünüyorsunuz?
Mart'ta

@skyking İzin sorunları aynı hatayı gösterir. Gerçekten de bu soruya başlık yüzünden geldim. Cevabımı olası bir çözüm olarak yazdım ve bazı oylar bunun diğer insanlara da gerçekleştiğini doğruladı;)
caligari

@caligari Tam olarak değil. İzin sorunu başka bir cevap veriyor ls project_path/.git/index.lock.
Mart'ta

5

del .git\index.lock benim için çalıştı.

Ana daldan yeni bir şube alırken bu sorunla karşı karşıya kaldım.

index.lockDosya silindikten sonra ödeme işlemi kolayca gerçekleşti .


4

Bazen Git, herhangi bir değişiklik yaparken veya büyük olasılıkla alt modüller kullanırken repo ile ilişkili bir kilit dosyası oluşturur. Hata mesajı size kilit dosyasının yolunu gösterecektir. Düzeltme: Terminaldeki yola manuel olarak gidin ve kilit dosyasını $ rm index.lock ile silin

Yardım etmeli.


4

SourceTree ile çift tıklatarak şube geçiş yaparken bu sorun vardı. Sorun çok yaygın değil ve Atlassian bunu biliyor ama düzeltmemeye karar verdiler.

Neyse ki, bir çözümü var. Değiştirmek istediğiniz dalı çift tıklamak yerine, sağ tıklayın ve "Checkout [dal adı]" seçeneğini seçin. Şimdi başarılı olmalı.


teşekkürler, sağ tıklama> ödeme alternatif olarak çalışır. hata iletisi özellikle index.lock mevcut olmadığında oldukça yanıltıcıdır.
Ernest

4

Ben de aynı senaryo ile karşılaştım. Yerel kodumda herhangi bir değişiklik bile yapmadım. Bir dosyayı yeni düzenledim ve geri aldım. Aşağıdaki dosyayı gizli .git klasöründe sildim. İşe yaradı!

project_path / .git / index.lock


3

Kökün repo'nuzun sahibi olmasını istemediğiniz sürece, bu yanlışlıkla Git komutunu kök olarak çalıştırdınız (belki de ilk klon / init). Bunu yapmak istiyorsanız, depodaki tüm Git komutlarını root olarak çalıştırmakla yaşamak zorunda kalacaksınız. Eğer yapmadıysanız sudo chown your-user[:your-group] -R .git, onun sahipliğini almaya çalışın ve sonra işlerin işe yarayıp yaramadığını görün.


Benim durumumda içindeki dosya ve dizinlerin modunu berbat .gitettim ve bunları düzelttim: find .git -type f -exec chmod 644 {} \;ve ayrıca find .git -type d -exec chmod 755 {} \;git projemi bir bilgisayardan diğerine taşırken modları berbat ettim
user3405291

Benim durumumda .git dosyalarına yazma izni ekledimsudo chmod g+w .git -R
Beatriz Fonseca

2

Aynı yerel depoda çalışan birden çok git istemcisi bu kilit için rekabet eder. Her müşteri, kilit, iyi bir vatandaş olmak için karşı taraf tarafından serbest bırakılıncaya kadar beklemelidir. Bizim için, SourceTree veya MSVS, büyük komut dosyaları çalıştırırken arka planda biraz bakım yapıyor gibi görünüyor.

Belki de 'git' kendisi yeniden denemeleri desteklemek için '--retriesWhenLocked 5' argümanını desteklemelidir.veya manuel olarak çalıştırıldığında bunu varsayılan olarak ayarlayabilirsiniz.

Burada "gitr" adlı bir PowerShell sarmalayıcısı, index.lock kaybolana kadar, her biri arasında 3 saniye varsayılan 5 deneme kullanılarak kaybolana kadar yeniden denenir. Kullanıcının müdahale etmesi gerektiğini varsayarak index.lock dosyasını asla kaldırmaz. Daha büyük bir komut dosyasından çıkarıldı. Sadece basit argümanlarla minimal testlere sahiptir.

  • Komut dosyasını C: \ bin dizinine kopyalayın ve C: \ bin dizinini $ PATH dizinine ekleyin.
  • PS1'den> gitr --help
  • DOS% 'dan> powershell gitr --help

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

Windows 10'da da bu sorum var.

del denediğimde ./.git/index.lockbana söyledicannot remove 'index.lock': Device or resource busy

Sonunda sebebim var:

bilgisayarda git kullanmak için iki işlem vardır:

  • git bash
  • cmder

bu yüzden cmder.exe kullanmak git commithataları oluşacaktır.

böylece çözüm kullanın git bashveya git bashsonra son cmder.exe kullanın


1

Bu aynı hatayı aldım, ancak sorun kilit dosyası değildi. Bunun yerine, başka bir git repo'nun içeriğini .git görünmez klasörü de dahil olmak üzere bu repoya kopyalamıştım. Yani, SourceTree hangi dosyaları repo etmek istediğim konusunda kafası karışmıştı (SourceTree'nin içinde olduğumu düşündüğüm ile gömülü .git diremin içeriğinin içinde olması gerektiğini söylediği repo arasında bir uyumsuzluk var).


1

Windows'da Cygwin ile TortoiseGit ile bu sorunu yaşadım. Yönetici ayrıcalıklarıyla bile kaldır ./.git/index.lock dosyasını silemedim, hem Cygwin hem de komut istemini denedim, dosyanın başka bir işlem tarafından kullanıldığını söyledi.

TortoiseProc.exe çalışan 2 örnekleri olduğunu buldum. Bunlardan birini öldürdüm ve tüm pencere gezgini pencerelerimi kapattım ve sonra dosyayı silebilirdim. TortoiseProc.exe örneğini öldürmenin çözüm mü yoksa windows explorer pencerelerini mi kapattığını bilmiyorum.


1

Benim için çözüm .index dosyasını silmek ve Git'in başka bir dosyayı yeniden oluşturmasına izin vermekti.


1

Silinecek bir inex.lock dosyam yoktu, ama benim için işe yarayan şey, Klasör Özellikleri iletişim kutusunun Özellikler penceresinden Salt Okunur denetimini kaldırmaktı.




1

Benim sourceTree uygulamasında taahhüt veya başka bir taahhüt / brach geçiş yapamıyorum. O zaman şu hatayı gösterir:

fatal: filan filan filan yaratılamıyor ..

Bunu goto .git klasörü (proje Gezgini Dizininde) ile çözüyorum. Ve Dizin ----- [dosya türü: KİLİT dosyası] silin. Şimdi sourceTree tüm erişim geri almak ..

Lütfen dizin kilit dosyası emin olun .. dosya türü alamadım varsayalım, dosya görünümü ayarlarını bilgisayarda değiştirin. Not: .git klasörü normalde gizli klasör türüdür.


1

Benim için ne yaptı:

git rebase --abort ve rebase'i yeniden başlatın.

Andrew'un belirttiği gibi , bu olduğunda PHPStorm'u da kullanıyordum. Yine de kapatmak zorunda değildi.


1

Öncelikle projenizin belirli bir klasörüne gitmelisiniz .. Proje adınız Firstproject ise, önce projenin dizinine gidin .. sonra cd .git yazın ve sonra git index türüne del index.lock'a gidin. index.lock dosyasının silinmesi ... Daha önce olduğu gibi taahhütte bulunabileceksiniz.


1

Benim durumumda, pencerelerdi, tamamen kapanmadı.

Windows hazırda bekletme moduna alındı, bağlanması reddedildi

Muhtemelen Windows gerçekten hazırda bekletilir. Windows bunu normal şekilde kapatmasını söylediğinizde otomatik olarak yapar. Avantajı, daha hızlı bir başlangıç ​​zamanı elde etmenizdir.

Windows'u hile yapmadan kapatmak için, komut isteminde (Windows'ta) aşağıdakileri yapın:

shutdown /s

Ayrıca dahil etmek isteyebilirsiniz /t 0 anında kapatma için .

Bunun için bir başlatıcı ayarlamak için güzel bir öğretici buldum: Hibrid Önyüklemeyi Devre Dışı Bırakmadan Windows 8'de Tam Kapatma Nasıl Yapılır.

Windows'u gerçekten kapatmanın daha basit yaklaşımı ('kapatma' yerine) 'yeniden başlatmak'tır, ancak daha sonra Windows'u önyüklemesine izin vermek yerine önyükleme işlemini durdurup Linux'u önyüklemektir.

kredi : nobar


1

Bu, hub gibi alternatif bir komut satırı git istemcisi kullanıyorsanız da olabilir .

Ben birkaç yıldır git için takma bir yedek olarak hub kullanıyorum, ama son zamanlarda git çalışması içinde bir sürü yapan bir bash betiği yazdı ve bu dizin kilidi sorunu almaya başladı.

Git yerine hub çalıştırdığımı hatırlayana kadar düzeltmeyi bulamadım. Bunu kaldırdım ve sorun ortadan kalktı!


0

Hatayı alma:

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.

Ancak .git / index.lock dosyasını bulamadım (veya silemedim).

Benim durumumda git-cola koşuyordu!

Açıkça bu .git / index.lock'u her seferinde oluşturur veya komut satırında yaptığım ve bu hatayı aldığım rebase neden olur - bu yüzden git-cola Git'in komut satırı çalışmasını açıkça "rahatsız eder" (veya bazı Git CLI işlemleri).

Bu, bir komut satırı git rebase sırasında git-cola kapatılarak çözülür.


0

Bazen başka bir Git istemcisi birden çok yüklendiğinde müdahale edebilir.

Yani. Görev Yöneticisi ile emin olun veya Get-Processo TGitCacheTortoiseGit arka planda etkin değildir.


0

Son zamanlarda aynı sorunu yaşadım. Tüm hata mesajını kontrol ederseniz, git işlemini kullanan index.lock'u silmenizi engelleyen bazı işlemler olduğunu da söyler. IDE'nin Visual Studio veya git'in entegre olduğu ilgili bir yazılım gibi açık olması olabilir. Kapatın ve dosyanızı yeniden saklamayı deneyin. Umarım yardımcı olur.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.