Почему выполнение `git status` c изменить результат последующего `git diff-index`?
Значит, вам нужен бит ls с начала текущей строки? Давайте посмотрим, что установлено zsh …
% foo(){ set > whatallisset }
% zle -N foo
% bindkey "^W" foo
% ls ./ # here I mash control+w, etc
% fgrep 'ls ./' whatallisset
BUFFER='ls ./ '
LBUFFER='ls ./ '
Таким образом, мы, вероятно, рассматриваем синтаксический анализ одной из этих переменных для «первого слова», поэтому предполагаем, что BUFFER является наиболее подходящим, а затем после просмотра документации zshexpn (1) и поиска вещей, связанных с "разделением":
foo(){ echo -n ${${(z)BUFFER}[1]} }
У меня была похожая проблема с git diff-files, и я думаю, что причина та же. Для этого не обязательно использовать Docker или нечувствительные к регистру -файловые системы, хотя это может усугубить проблему.
Git поддерживает кеширование информации о содержимом файлов. Обычно это прозрачно, и команды высокого уровня -, такие как git statusи git diff, обновляют кэш по мере необходимости.
Команды нижнего -уровня, такие как git diff-indexи git diff-files, предназначены для быстрого возврата приблизительных результатов. Кэш они не обновляют. Они возвращают 0, если уверены, что вещи, которые они сравнивают, идентичны, но когда они возвращают 1, это означает только «я не знаю, что вещи идентичны». Если записи кэша устарели, возможно, они идентичны, но git diff-xxxне знает.
Я точно не знаю, как работает кеш. В вашем первом эксперименте кажется, что первый вызов git diff-indexзаметил, что запись кэша устарела, и поэтому вернул 1 для «я не знаю». Затем git statusобновил кеш, а второй вызов git diff-indexувидел действительные записи кеша и смог сделать вывод, что файлы идентичны. Во втором эксперименте запуск git statusвне контейнера Docker, по-видимому, создал записи кэша, которые git diff-indexвнутри контейнера считались устаревшими, поэтому второй вызов git diff-indexвернул 1 для «Я не знаю».
Мое решение состояло в том, чтобы забыть о командах низкого -уровня и придерживаться git diff --quiet.