(Стоит упомянуть: это специальное поведение на основе слияния относится только к git diff.)
Это невозможно, поскольку ни индекс, ни рабочее дерево не являются коммитом.Расчет базы слияния выполняется с двумя коммитами в качестве входных данных.
Точнее, git diff A...B анализирует A...B, используя тот же код, что и git rev-parse:
$ git rev-parse origin/master...master
80b88a51c112215a56f0e73dab804c4e17248f3b
3afc4b6899bfb87ca3e397c62463fc9cdd070fb6
^3afc4b6899bfb87ca3e397c62463fc9cdd070fb6
Выход извышеприведенный git rev-parse в простых случаях, подобных описанным выше, представляет собой три хеш-идентификатора: идентификатор с правой стороны, идентификатор у базы слияния и - отрицание - у левой стороны.(Если существует несколько баз слияний, все они находятся между RHS и LHS с отрицанием.)
Внутри git diff эти же идентификаторы хеша фиксации отображаются в массиве в том же порядке (индекс)ноль, представляющий неотрицательную RHS).Код diff замечает, что имеется несколько положительных ссылок и одна окончательная отрицательная ссылка, и запускает git diff для двух хеш-идентификаторов фиксации: одной из основ слияния из середины и неотрицательного хеш-идентификатора в нулевом индексе.
Поскольку ни у индекса, ни у рабочего дерева нет идентификатора фиксации, git diff не может передать их в код анализа ревизии.Это означает, что этот же кусок кода не может возвращать массив с тремя или более элементами, последний из которых помечен как «отрицательный».
Git может , но не может иметь совершенно другой кодчтобы справиться с этим.Но так как это всего лишь удобный синтаксис, вы можете сделать это самостоятельно:
git diff $(git merge-base master HEAD)
для сравнения базы слияния master и HEAD (или одной случайно выбранной базы слияния, в случае нескольких баз) к текущему рабочему дереву или добавьте --cached, чтобы сравнить ту же базу слияния с индексом.