Как явно сослаться на текущее незафиксированное состояние репо в git diff

Question

Когда вы запускаете git diff или git diff <some commit>, вы неявно отражаете текущее состояние репо (независимо от того, является ли оно поэтапным или нет) неявно против HEAD в первом случае или любого другого коммита, указанного в последнем случае.

Мой вопрос: как я могу явно сослаться на текущее состояние репо?
В идеале, я хотел бы назвать что-то вроде git diff CURRENT_STATE HEAD.

Answer 1

как я могу явно сослаться на текущее состояние [рабочего дерева]?

git diff уже является явной ссылкой на это, Git сравнивает с текущим состояниемдерево работы, если вы не переопределите его и не скажете, чтобы оно сравнивалось с содержимым где-то еще, но если вы хотите после дополнительного переопределения, например --no-cached, переопределить любое более раннее переопределение --cached, то git diff не имеет вна данный момент вам придется написать небольшой препроцессор параметров, чтобы удалить все, что вам не нравится, вместо того, чтобы просто переопределить конец в конце.

edit:

В идеале,Я хотел бы назвать что-то вроде git diff CURRENT_STATE HEAD

Вы можете получить этот эффект с -R, обратным дифференциалом, который меняет обычный порядок. Вы бы сделали этот конкретный diff только с git diff -R HEAD (я бы предпочел синоним @ для HEAD, git diff -R @).

Answer 2

jthill ответ в порядке;Я просто хочу обратиться к этому комментарию напрямую, с гораздо большей детализацией и форматированием, чем уместится в комментарии:

По сути, я спрашиваю: имеет ли незафиксированное состояние репо явно свой собственный ref?

Краткий ответ "нет".

Ссылка, например HEAD или master или (полностью прописано) refs/heads/master, в конечном итоге разрешается в хешID. ¹ Если это имя ветви или имя удаленного слежения, оно разрешается конкретно в commit ID хэша;если это имя tag , оно может быть разрешено для любого из четырех внутренних типов объектов Git: commit, tree, blob или (annotated) tag.

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

Если индекс находится в хорошемсостояние, ² вы можете запустить git write-tree. Результатом является хэш-идентификатор. Это вообще не ссылочное имя, это просто хеш-идентификатор, но хеш-идентификатор обычно так же хорош. Поэтому, если вы хотите, чтобы какая-то команда Git обратила внимание на предложенный следующий коммит, вы можете запустить git write-tree, чтобы записать его в объект дерева, а затем использовать полученный хеш-идентификатор.

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

Команды git diff и git status имеют встроенные приемы для использования индекса и рабочего дерева как если бы они были коммитами, но большинство других команд Git этого не делают.

---

¹ Если ссылка символическая - как HEAD обычно так и есть - просто содержит имя другого реф. Если эта другая ссылка на самом деле не существует, символическая ссылка вообще не преобразуется в хэш-идентификатор, и git rev-parse не удастся выполнить, но git symbolic-ref позволит вам изучить цель.

² Индекс может находиться в состоянии конфликта слияния , в котором он не может быть преобразован в объект дерева. В этом случае git write-tree просто ошибки. К сожалению, нет другого способа справиться с этим, кроме как просто разрешить конфликты слияния. Я говорю «к сожалению», потому что иногда было бы очень удобно спрятать (как будто на git stash или что-то подобное) конфликтующее состояние для хранения и / или транспортировки, и то, как Git сегодня, это просто невозможно. Вы можете подойти довольно близко, используя git ls-files --stage, чтобы перевести индекс в текст, и git update-index, чтобы инвертировать его, но защита временных хэшей больших двоичных объектов от GC является проблемой.

Answer 3

вы можете указать два коммита для git diff:

git diff [--options] <commit> <commit> [--] [<path>...]
   This is to view the changes between two arbitrary <commit>.

Пожалуйста, напишите:

git help diff

Для дополнительных опций.

Удачи!