fatal: невозможно создать 'C: /Users/TONY/lambdaschoolprecourse/precourse/.git/index.lock': файл существует [дубликат]

Для Windows:

• Из консоли командной строки, открытой как admin, попробуйте

> rm -Force ./.git/index.lock

• Если это не работает, вы должны убить все процессы git.exe

> 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

Это может быть старый ответ, но я надеюсь, что это будет более полезно для следующего, кому нужно это решение.

В linux / unix / gitbash / cygwin попробуйте

rm -f .git/index.lock

В командной строке Windows попробуйте:

del .git\index.lock

Надеюсь, что это поможет, я нашел это решение здесь: Fatal: не удалось create '... git / index.lock' Файл существует

Недавно у меня была такая же проблема. Если вы проверите все сообщение об ошибке, оно также сообщит, что есть какой-то процесс, который использует процесс git, который блокирует вас от удаления index.lock. У вас может быть IDE открытым, как Visual Studio или связанное с ним программное обеспечение, в которое интегрировано git. Закройте его и попробуйте перезаписать файл. Надеюсь, что это поможет.

Вероятно (это случилось со мной), команда ls говорит, что она не существует , потому что у текущего пользователя нет разрешений для доступа к этому каталогу или файлу.

Удалите блокировку и убедитесь, что вы выполняете git с нужным пользователем, чтобы избежать проблем с правами.

Если вы находитесь в поле GNU / Linux с sudo :

sudo rm project_path / .git / index.lock

Решение для меня состояло в том, чтобы удалить файл .index и позволить Git перестроить другой.

Если вы на самом деле не предназначались для root для вашего репо, это звучит так, будто вы случайно запускали команду Git как root (возможно, даже начальный клон / init). Если вы хотели это сделать, вам придется жить с запуском всех команд Git в репо с правами root. Если вы этого не сделали, запустите sudo chown your-user[:your-group] -R .git, чтобы взять на себя ответственность за это, а затем посмотреть, все ли работает.

Несколько клиентов git, работающих в одном локальном репозитории, конкурируют за эту блокировку. Каждый клиент должен ждать, пока блокировка не будет освобождена другой стороной, чтобы быть хорошим гражданином. Для нас SourceTree или MSVS, похоже, выполняют некоторое обслуживание в фоновом режиме, пока мы выполняем большие скрипты фиксации.

Возможно, сам git должен поддерживать аргумент '--retriesWhenLocked 5' для поддержки попыток. или даже по умолчанию для этого при запуске вручную.

Вот оболочка PowerShell вокруг git с именем «gitr», которая повторяет попытку, пока index.lock не исчезнет, ​​используя по умолчанию 5 попыток, 3 секунды между каждым. Он никогда не удаляет index.lock, предполагая, что пользователь должен вмешаться. Он был извлечен из большого скрипта фиксации.

• Скопируйте сценарий в C: \ bin и добавьте C: \ bin в $ PATH.
• Из PS1> gitr --help
• Из DOS%> 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
}

Получение ошибки:

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.

Но я не смог найти (или удалить) этот файл .git / index.lock.

В моем случае git-cola был запущен!

Он явно создает этот .git / index.lock каждый раз в то время, или вызванный rebase, который я делал в командной строке, и в течение которого я получил эту ошибку - так что git-cola очевидно, «нарушает» запуск командной строки Git (или некоторые операции Git CLI).

Это решается путем закрытия git-cola во время перестановки git командной строки.

1. проверьте, если git все еще работает (ps -ef | grep git)
2. , если нет, удалите заблокированный файл
3. , если да, сначала уничтожьте git-процесс .

У меня была такая же ошибка, но проблема была не в файле блокировки. Вместо этого проблема заключалась в том, что я скопировал содержимое другого git-репо в это репо, в том числе .git-невидимую папку. Итак, SourceTree был смущен, о том, какой репо я хотел бы сгенерировать файлы (там было несоответствие между репо SourceTree, в котором я был, и тем, что содержимое моего встроенного .git-файла говорит, что я должен быть).

Что для меня было:

git rebase --abort и перезапустить rebase.

Как упоминалось Andrew , я также использовал PHPStorm, когда это произошло , Не нужно было закрывать его.

Я создал пустой файл index.lock, удалив его с помощью команды windows

У меня также есть этот вопрос в Windows 10.

, когда я пытаюсь del ./.git/index.lock, он сказал мне cannot remove 'index.lock': Device or resource busy

Наконец-то я получил причину:

у компьютера есть два процесса для использования git:

• git bash
• cmder

, поэтому я использую cmder.exe для git commit будут возникать ошибки.

, поэтому решение используется git bash или Завершить git bash, затем используйте cmder.exe

В моем приложении sourceTree я не могу выполнить фиксацию или переключиться на любой другой commit / brach. Это время показывает ошибку, как

fatal: Невозможно создать blah blah blah ..

Я просто разрешаю это с помощью папки goto .git (в Project Explorer Dir). И удалите Индекс ----- [тип файла: LOCK-файл]. Теперь я возвращаю весь доступ в sourceTree ..

, пожалуйста, убедитесь, что файл блокировки индекса .. предположим, что вы не получаете тип файла, меняете Настройки просмотра файлов на компьютере. Примечание: папка .git обычно является скрытым типом папки.

В диспетчере задач:

1. разработать весь процесс
2. Убить все git-процессы
3. Удалить заблокированный файл

У меня возникла проблема с SourceTree при переключении ветки, дважды щелкнув по ней. Проблема не очень распространена, и Atlassian знает об этом , но они решили не исправлять ее.

К счастью, есть решение. Вместо двойного щелчка по ветке, которую вы хотите переключить, просто щелкните правой кнопкой мыши и выберите «Checkout [название ветки]». Теперь это должно преуспеть.

Иногда другой клиент Git может вмешиваться при наличии нескольких установленных.

Т.е. убедитесь, что с Диспетчером задач или Get-Process, что TGitCache из TortoiseGit не активен в фоновом режиме.

Если вы используете GIT BASH для Windows: -

Запустите эти две команды: 1. cd .git 2. rm index.lock

Просто эта проблема ... Gitbox был виноват. Возможно, у вас был запуск графического интерфейса, который вызывал проблемы.

Это происходит, когда вы отменяете выделение с начала координат посередине.

, поэтому вы можете вручную удалить файл index.lock из вашего каталога .git.

rm -f ./.git/index.lock

cd в каталог проекта и запустите эту команду.

У меня была эта проблема с TortoiseGit с Cygwin в Windows. Я не смог удалить remove ./.git/index.lock даже с правами администратора, я попробовал оба Cygwin и командной строки, он сказал, что файл использовался другим процессом.

Я обнаружил, что у меня было 2 экземпляра TortoiseProc.exe. Я убил одного из них и закрыл все окна окон, а затем смог удалить файл. Я не знаю, было ли убийство экземпляра TortoiseProc.exe решением или закрытием окон Windows Explorer.

del .git\index.lock работал для меня.

Я столкнулся с этой проблемой, проверяя новую ветку от главной ветки.

После удаления файла index.lock произошла ошибка при загрузке.

ok Я решил эту проблему.

1. Закройте все окна, которые потенциально влияют на этот файл .git / index.lock
2. Удалите .git / index.lock file.
3. Откройте ваш редактор командной строки и cd в адрес ваших git-файлов.

(Если файл создан, просто из cd в это место, тогда проблема заключается в вашем редакторе. Закройте редактор. Не используйте этот редактор для этой задачи. Откройте другой вид редактора - оболочку оболочки Windows или просто cmd. Теперь вы можете использовать команды git для продолжения)

Иногда Git создает файл блокировки, связанный с вашим репо, когда вы вносите какие-либо изменения или, скорее всего, когда используете вспомогательные модули. Сообщение об ошибке покажет вам путь к файлу блокировки. Исправить: просто вручную перейдите на путь в терминале и удалите файл блокировки с помощью $ rm index.lock

Это должно помочь.

У меня не было файла index.lock для удаления, но для меня работало удаление проверки только для чтения из окна «Атрибуты» диалогового окна «Свойства папки».

Запуск git 2.8.4 (июнь 2016) , этого больше не должно быть.

См. issue 755 , который также должен облегчить проблему ( commit 2db0641 ):

Убедитесь, что временные дескрипторы файлов не наследуются дочерними процессами

Предотвращение наследования дочерних процессов с помощью дескриптора index.lock .

На платформе Windows, использующей Visual Studio 2015 RC (v4.6.00057) в сочетании с SourceTree (v1.6.14.0), также будет указана эта ошибка.

Решение. Предполагая, что вы хотите использовать исходное дерево в качестве менеджера исходного кода, просто отключите поставщика управления источником внутри Visual Studio следующим образом:

1. Перейдите в меню «Инструменты»> «Параметры»> Source Control
2. Выберите плагин управления токовым источником как: None