открыть файл репо вместо файла tmp для изменения в git difftool - PullRequest
0 голосов
/ 15 ноября 2018

git difftool --tool=vimdiff --no-prompt HEAD~1 HEAD

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

1 Ответ

0 голосов
/ 15 ноября 2018

Нет: поскольку вы выбрали две конкретные фиксации , не содержит файлов для изменения .

Это кажется немного странным, чтобы сказать. На самом деле немного немного странно, пока вы не поймете, что такое коммиты: пока коммиты содержат файлы, 1 файлы, которые они содержат, заморожены . Ни один из них не может быть изменен. Они совершены , а содержимое любого коммита так же постоянно, как и сам коммит, 2 и полностью доступно только для чтения.

Конечно, когда вы используете Git, у вас есть файлы, которые вы можете изменить. Если бы вы этого не сделали, было бы трудно использовать Git. Но это не совершенные файлы: это рабочее дерево копий. Если вы дадите указание git difftool --tool=vimdiff использовать эти файлы в качестве одной из сторон операции, он уже откроет эти файлы напрямую. Для этого:

git difftool --tool=vimdiff <options> <commit>

, где <options> включает ваши --no-prompt, а <commit> может быть снова HEAD~1, например.

(Как и в случае git diff, git difftool может быть приказано сравнить два коммита или сравнить один коммит с текущим рабочим деревом. Нет возможности сравнить коммит с текущим index содержание. Остальная часть этого ответа не упоминает индекс, но индекс содержит третью копию каждого файла. Файлы внутри коммитов имеют специальный, только для чтения, формат Git-only. Файлы в ваше рабочее дерево находится в удобном формате, так что вы можете читать или редактировать его напрямую. Файлы в вашем index находятся в промежуточной зоне, между фиксацией HEAD, где они заморожены, и работой -дерево, где они нормальны: индексные копии не заморожены, но все еще Git-only и сжаты. Git делает новые коммиты из индексной копии, поэтому вам нужно продолжать git add все время.)


1 Технически, коммит не столько содержит файлов, сколько относится к файлам. Файлы хранятся с использованием ряда косвенных указаний: коммиты указывают на дерево объектов, которые дают имя файла, режим и идентификатор хеша для содержимого; а затем идентификатор хэша в дереве указывает на объект Git blob , который сохраняет содержимое файла. Это позволяет двум разным деревьям (возможно, с разными режимами или разными наборами файлов) повторно использовать существующее замороженное содержимое файла и позволяет различным коммитам (возможно, с разными авторами или временными метками) повторно использовать существующие замороженные деревья, которые повторно используют существующие замороженные файлы. совершает. Это всего лишь один из нескольких приемов, которые Git использует для экономии места, хотя каждый коммит хранит полную и полную копию каждого файла: под капотом происходит многократное использование старых файлов.

2 Коммит обычно живет вечно, но если каждый, у кого есть какой-то коммит - как определено по некоторому хэш-идентификатору, - соглашается прекратить использование этого коммита навсегда и забирает его History-list, Git в конце концов забудет коммит по-настоящему. Если кто-то не согласен, он может легко снова ввести коммит, и фактически это значение по умолчанию. Поэтому от коммитов трудно окончательно избавиться после того, как они были распространены в другие репозитории Git, потому что для того, чтобы избавиться от них навсегда, вы должны выбросить их из каждого репозитория Git, который их забрал.

...