Подкаталоги в извлеченном каталоге предыдущей ревизии не исчезают в Git? - PullRequest
Новая
       60

Подкаталоги в извлеченном каталоге предыдущей ревизии не исчезают в Git?

3 голосов
/ 02 мая 2011

Я пытаюсь использовать git checkout <hash> <directory> для проверки предыдущей версии каталога в моем репо.Это работает для восстановления файлов в каталоге до их прежнего состояния, единственная проблема заключается в том, что подкаталоги, которые были добавлены после извлеченной мной ревизии, не исчезают.

Например, если моя структура каталогов была следующей: 

HEAD:
thing/dir1/
thing/dir2/

HEAD^:
thing/dir1/

Если я сделаю git checkout <hash>, то я перехожу в режим отсоединенного HEAD, и все отлично подходит.Если вместо этого я сделаю git checkout <hash> thing/, содержимое thing/dir1/ вернется, но thing/dir2/ останется на месте.

Запуск git status показывает изменения файла с thing/dir1/, но не упоминает thing/dir2/.Это странно, потому что в контексте HEAD ^, thing/dir2/ не должно существовать и поэтому должно исчезнуть.git clean не помогает, потому что он даже не отображается как неотслеживаемый.

Есть ли способ извлечь предыдущую версию каталога, которая полностью совпадает, без необходимости извлекать все рабочее дерево?

ОБНОВЛЕНИЕ:

Похоже, это будет работать: 

git reset <hash> thing/
git checkout <hash> thing/
git clean -fd thing/

Это оставляет мое рабочее дерево и индекс в странном состоянии, но имеет желаемоеэффект.

Ответы [ 2 ]

1 голос
/ 02 мая 2011

С http://git -scm.com / docs / git-checkout :

Обновляет файлы в рабочем дереве в соответствии с версией в индексе илиуказанное дерево .Если пути не указаны, git checkout также обновит HEAD, чтобы установить указанную ветвь в качестве текущей.

Далее ниже также написано:

Когда или --patch даны, git checkout не переключает ветви .Он обновляет именованные пути в рабочем дереве из индексного файла или из именованного (чаще всего коммит).В этом случае параметры -b и --track не имеют смысла, и их выдача приводит к ошибке.Аргумент может использоваться для указания конкретного дерева (т. Е. Коммита, тега или дерева) для обновления индекса для указанных путей перед обновлением рабочего дерева.

Другими словами, так как выне переключая ветки, рабочий каталог не будет отражать какие-либо изменения в указателе HEAD, но покажет файлы, которые принадлежат tree-ish, в данном случае это HEAD ^

причина, по которой вещь / dir2 все еще остаетсяна диске это то, что он все еще принадлежит текущей HEAD (помните, что HEAD не перемещается), и нет никакой информации в древовидной структуре, чего не хватает в тройной (в данном случае thing / Dir2).Таким образом, в действительности вы извлекли вещь / dir1, чтобы отразить состояние хэша HEAD ^, а также вещь / dir2 на диске, поскольку он принадлежит HEAD.

1 голос
/ 02 мая 2011

Как вы уже упоминали, git checkout <hash> заставляет git перейти в режим отдельной головы .При проверке определенных файлов действительно только файлы копируются в ваш рабочий каталог, а все остальное остается нетронутым.

Таким образом, файлы в thing/dir2/ не отображаются в git status, потому что они находятся в текущем состояниииз HEAD, в то время как thing/dir1 покажет измененные файлы.

Если вы действительно хотите иметь всю папку thing/, как в последней ревизии, почему бы просто не удалить ее раньше? 

rm thing/
git checkout <hash> thing/

Я не уверен, соответствует ли это вашим потребностям.Используйте с осторожностью!(Хотя при отсутствии локальных незафиксированных изменений все должно быть восстановимым.)

...