Что делать после запуска ловушки предварительной фиксации?

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

Ловушка перед фиксацией применяет некоторую красивую печать к файлам, которые должны быть зафиксированы. Хук выполняет следующие задачи:

  • заменяет табуляцию пробелами
  • удаляет завершающие пробелы в конце строк
  • удаляет двойные пустые строки *)
  • если отсутствует, добавляет пустую строку в конец файла *)

Действия, отмеченные *) , вызывают описанную ниже проблему.

После того, как это было сделано, ловушка добавляет измененный файл (ы) в индекс, используя git add $ filename . Таким образом, выполняется постановка всего файла, и я больше не могу фиксировать только небольшие части (т. Е. Фрагменты) измененного файла.

Конечно, я мог git add --no-verify и обойти ловушку, но эта опция недоступна при использовании git gui . Кроме того, я хочу, чтобы дубль применил красивую печать к поэтапным строкам файла, поэтому обход ловушки не является моей целью.

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


Редактировать 1:
Хотя ответ , предоставленный Дэвидом Бригада , выглядит многообещающим, он не работает: git stash --keep-index оставляет поэтапные изменения нетронутыми (это хорошая часть), но (по крайней мере, в msysgit) помещает все изменения в тайник (не только неустановленные). Это приводит к конфликтам слияния при возвращении тайника в WC, потому что поэтапные строки могут быть изменены.


Редактировать 2:
Также обновленный ответ Дэвида не приводит к успеху, поскольку git отказывается объединить тайник с грязным WC.


Редактировать 3:
Ответ от larsks указывает мне на использование .gitattributes . На первый взгляд, это кажется правильным, но меня довольно сбивает с толку то, что зарегистрированная версия была пропущена через фильтр, а WC отличается от зарегистрированной версии.По крайней мере, это был мой опыт, и это подтверждается следующим замечанием в Git Book :

Если вы зафиксируете эти изменения и снова проверите файл, вы увидите, что ключевое слово подставлено правильно

Мне нужно удалить файл, а затем проверить его снова , чтобы увидеть изменения, примененные фильтром? Ни за что! Есть еще подсказки?

7
задан 13 revs 23 May 2017 в 11:51
поделиться