git update-index --assume-неизмененный возвращает «фатальный невозможно пометить файл»

У меня та же проблема, что и у ОП в этом посте, но я не понимаю ответ, помеченный как правильный (не вижу, чтобы он объяснял, как исправить ситуацию)

Я делаю это и получаю эту ошибку:

$ git update-index --assume-unchanged web.config
fatal: Unable to mark file web.config

1. Файл добавлен в хранилище

2. Это не в .git/info/exclude

3. Это не в .gitignore(это было, но я вынул его, затем принудительно добавил web.config git add -f web.config, зафиксировал и отправил эти изменения в репозиторий)

4. Когда я делаю Git ls-files -o, его там нет

Так что я могу сделать, чтобы исправить?

У меня была та же проблема, что и у вас, и я выполнил те же четыре шага, которые вы указали выше, и получил те же результаты. Это включало тот факт, что мой файл был указан при выполнении git ls-files -o. Однако в моем случае я также попытался выполнить git update-index --assume-unchangedфайл, который не был указан при выполнении ls-files -o, и я все еще получил ту же ошибку " fatal: Unable to mark file".

Я подумал, что, возможно, это ошибка, и скачал последнюю версию git, но это не помогло.

Я наконец понял, что эта команда чувствительна к регистру! Это включает в себя полный путь и имя файла. После обновления пути к каталогу, чтобы полный путь был указан в правильном регистре, команда выполнена правильно.

Обратите внимание, что это было с Git для Windows, поэтому ваши результаты могут отличаться в зависимости от других платформ.

У меня была такая же проблема на Mac. Чувствительность к регистру не была для меня проблемой - проблема была в том, что мне нужно было сначала сбросить свой мерзавец:

Проблема:

 git update-index --assume-unchanged index.php
 fatal: Unable to mark file index.php

Решение:

git reset HEAD
Unstaged changes after reset:
M   index.php
git update-index --assume-unchanged index.php

В моем случае дерево, которое я отмечал, было каталогом, а не файлом, как в вашем случае, и мне не хватало косой черты после его имени.

Неправильно -

git update-index --assume-unchanged directory-name

Верный -

git update-index --assume-unchanged directory-name/

Обратите внимание на косую черту (/) в конце.

Неустранимый: невозможно пометить файл Localization / el-GR.js

Что вы можете сделать, это:

1. Перейти к правильному пути, где файл присутствует в вашем локальном (в GITBASH)
2. Обновить индекс $git update-index --assume-unchanged <file name>

Это помогло мне! :)

Если в вашем пути есть пробелы, вы можете получить эту ошибку, даже если у вас есть правильная оболочка.

Это приводит к «фатальной» ошибке:

git update-index --assume-unchanged code/Solution Files/WebEssentials-Settings-json

Чтобы исправить это, просто добавьте кавычки вокруг пути.

git update-index --assume-unchanged "code/Solution Files/WebEssentials-Settings-json"

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

Так что я сделал

$ git reset HEAD
Unstaged changes after reset: 
M   .gradle/1.9/taskArtifacts/cache.properties.lock
M   .gradle/1.9/taskArtifacts/fileHashes.bin
M   .gradle/1.9/taskArtifacts/fileSnapshots.bin
M   .gradle/1.9/taskArtifacts/outputFileStates.bin
M   .gradle/1.9/taskArtifacts/taskArtifacts.bin

проведение

$ git update-index --assume-unchanged .gradle/1.9/taskArtifacts/*

работал для меня тогда и не привел к ОП и моей проблеме.

У меня была эта проблема, когда я пытался распаковать файлы * .orig.

Вот что я сделал, чтобы отследить их:

$git reset -- *.orig

если это не сработает:

$git clean -fd

Убедитесь, что файл добавлен в git repo, если не добавляете файл в git repo, а затем попробуйте, он будет работать.

--assume-unchangedо медленных файловых системах, и пользователи обещают, что Git не нужно проверять этот файл, поскольку Git может предположить, что он не изменился. Но некоторые команды все же проверяют и выдают «сюрприз»!

Не используйте на файлы, которые меняются.

Извините, что принес эти новости (у меня есть патч в процессе изменения этой документации).

В моем случае я попытался использовать любой из вышеперечисленных методов, но безуспешно.

После многих попыток я просто подумал добавить свой файл для индексации.

git add myfile.php

Git отказался от этого действия, но посоветовал мне сделать это принудительно.

git add myfile.php -f

И это сработало для меня.

Убедитесь, что у вас есть "web.config".

Если это не так, вы получите это сообщение об ошибке.

Может кому пригодится. У меня была такая же проблема, и не было проблем с синтаксисом, без имени с пробелами, без проблем с путями и команда git reset не работала. Я делал коммит из папки внутри apache www, и служба apache была остановлена. Снова запущена служба apache, и ошибка исчезла

Одна из распространенных ошибок при использовании этой команды - это попытка предположить, что файл либо не отслеживается, либо уже игнорируется git.

Сначала убедитесь, что файл отслеживается, запустив

git ls-files | grep relative_path/to/file

Если он не показывает ваш файл, вам нужно сначала добавить его:

git add relative_path/to/file

Если это показывает ваш файл или вы уже добавили этот файл в git, тогда вы сможете нормально запускать команды git accept:

git update-index --skip-worktree relative_path/to/file

или для папок

git update-index --skip-worktree relative_path/to/folder/

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

git ls-files -v | grep ^S

Символ S представляет пропущенные файлы.

Для всех будущих посетителей. Ничего из вышеперечисленного не решило мою проблему. Я понял, что .gitignoreфайл должен быть помещен в правильный каталог. В моем случае, когда я перешел .gitignoreв корневой каталог приложения, проблема была решена.

Убедитесь, что помечаемый файл существует и правильно написан, особенно путь к файлу и разделитель файлов. Разделители файлов в системе Windows и системе Linux разнесены.

Я обнаружил, что иногда это не работает, потому что вы уже передали файл в свой .gitignore и сделали push или pull. Вам нужно только сделать push, и ваш файл должен игнорироваться при последующих фиксациях, даже если вы локально изменяете файл.

У меня была такая же проблема с cygwin в Windows. Предоставление полного пути к файлу