Однако, если я проверить несортированный файл будет отсортирован сразу фильтром
Это не должно произойти (я думаю!). Я считаю, что на самом деле происходит что-то еще.
Цели/идея clean фильтра является то, что она применяется , когда файл добавляется к индексу и смазыванию фильтр применяется , когда файл является экстрактом из индекса в рабочих дерева (поэтому git checkout должен сначала записать файл из фиксации в индекс, прежде чем копировать его в дерево работы, когда вы используете git checkout <commit> -- <path>). Обратите внимание, что преобразования конца строки/CRLF рассматриваются как форма фильтра (если это возможно, делается внутренне, но, если необходимо, выполняются на канале от или до вашего фактического фильтра, предоставленного пользователем).
(Вполне возможно, что есть некоторый код, который я пропустил где-то, что делает запускает clean фильтра в некоторых дополнительных случае Но я не думаю так:.. Эта часть источника Git довольно очевидно)
Я считаю, что происходит более тонко. Когда Git применяет фильтр smudge, он автоматически помещает запись в кэш «грязный» в индекс. (Этот код значительно менее очевиден, поэтому я могу ошибаться.) Из-за этой маркировки, когда Git отправляется в , проверьте статус файла, он говорит: Хм, эта запись в кеше отмечена грязной, я бы лучше всего запустите фильтр clean и узнайте наверняка. Итак, он запускает ваш фильтр clean, который сортирует пары ключ/значение, а затем сравнивает результат с базовым блобом. Они отличаются друг от друга, поэтому Git теперь объявляет запись дерева работы «действительно грязной», , хотя исходная, несортированная запись рабочего дерева фактически соответствует текущему фиксации.
Другими словами, Git предполагает, что эквивалент git cat-file <hash-id> | smudge | clean производит же биты, как git cat-file <hash-id>, и если это не произойдет, вы должны зафиксировать файл-который на самом деле обычно верно, когда вы пытаетесь нормализовать концы строк как хранится в репозитории. Это не означает, что отсортированная копия сортируется; ваш фильтр cat (который, к слову, вы можете отказаться: несуществующий фильтр означает «оставьте это в покое») не сортировал файл, а копия рабочего дерева по-прежнему не сортирована. Просто Git настаивает на том, чтобы он стал отсортированным.
Что это означает, что, в конце концов, ответ на:
Как можно отменить изменения, сделанные с помощью фильтра без совершения?
должен просто игнорировать жалобы Git и в любом случае проверять другие фиксации. Возможно, вам придется использовать флаг --force, чтобы сделать это, хотя это в лучшем случае тревожит (и в худшем случае может привести к потере изменений, которые вы намеревались сохранить!). Итак, есть несколько лучший метод (ish): временно отключите «чистый» фильтр (путем редактирования .gitattributes).
С отключенным фильтром (или заменен на cat, что делает то же самое только медленнее), Git теперь, после проверки состояния, увидит, что установлен флаг «грязный», и повторите его Хм, я бы лучший запуск clean фильтр предмет. На этот раз фильтр не работает, результирующие двоичные бит совпадают с блобом, а Git очищает грязный флаг. Теперь вы можете восстановить фильтр в любой момент, потому что теперь запись в кеше перестала быть грязной, и Git пропустит все это тестирование.
(Это было бы неплохо, чтобы иметь возможность получить Git попробовать два сравнения, прежде чем объявить файл «действительно грязный»: один с использованием фактического, сконфигурированный clean фильтра, а затем, если это говорит «грязное», один more время с использованием no filter. Это автоматически решит, что файлы рабочих деревьев, основанные на «неочищенном» блоке repo, но в конечном итоге совпадают с этим блобом, на самом деле «не загрязнены». означает, что вам не рекомендуется исправлять окончание строк, но если это был пользовательский переключатель, вы можете установить его для старых репозиториев, содержащих нечистые объекты, так же, как вы можете установить merge.renormalize для таких репозиториев.)
Итак, вы меняете файл (автоматически), а 'git reset' не работает? Или, может быть, он работает, но меняет его после сброса, так что ничего не получается – miva2
Это именно то, что происходит - файл сортируется снова после запуска 'git reset'. Я только ожидал, что он будет сортировать при постановке файла resx, но он также делает это при сбросе. –
Я только что прочитал о git-фильтрах [здесь] (https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes), никогда не использовал их. 'clean' запускается перед тем, как быть поставленным, и' smudge' запускается после проверки. Итак, вы хотите, чтобы они были отсортированы перед фиксацией и несортированы после проверки? Я думаю, что тогда он покажет файл как измененный в вашей промежуточной области и отсортирует его, когда вы зафиксируете, таким образом не показывая ничего в diff после вашего фиксации, если вы его не изменили. Или вы можете отсортировать его всегда и использовать SortRESX для «чистого» и «smudge». Я просто догадываюсь. – miva2