2015-04-20 3 views
2

Мне нужно проанализировать, что именно произошло с некоторыми файлами в данном каталоге за всю историю, и использовать такие вещи, как git log the_directory, недостаточно. Поэтому, хотя я бы создал ветку, содержащую только соответствующие файлы.Confused by git filter-branch

Я написал сценарий perl remove-all-but-stuff и проверил, что он работает правильно. Сначала я думал, что просто удаление файлов будет делать, но я установил его использовать

system qw(git rm -r --ignore-unmatch --quiet), @files 

где @files содержит ненужные файлы и каталоги , поскольку они находятся в рабочем дереве - может ли это быть проблема?

Я создал новую ветвь и фильтруют его через

git filter-branch --tree-filter remove-all-but-stuff my-branch 

и в конце файлы ушли, но это происходит в самой последней фиксации. История содержит изменения в файлах, которые не должны существовать.

Я использую git версию 2.3.5. Любая идея, что я делаю неправильно?


Теперь я даже добавил несколько путей к @files, не смотря на то, если существуют. Что-то изменилось (Ref 'refs/heads/my-branch' был переписан), но нежелательные файлы (даже ниже добавленных путей) все еще находятся в истории.

+0

Я просто оставляю это здесь: git gui wame somefile.txt предоставляет графический интерфейс, представляющий файл и источник всей модификации. вы можете перемещаться по истории файла, нажимая на хеш фиксации, связанной с каждой строкой. Это лучший способ (imo), чтобы посмотреть историю файла в глубину. –

+0

@ FélixCantournet Моя проблема - это куча файлов и много изменений в них (и только два переименования). Указание их в командной строке является большой болью из-за файлов с пробелами в именах и подобных преступлениях. То, что у меня есть после фильтрации, намного лучше. – maaartinus

ответ

0

Это довольно глупо, но это была ошибка на моей стороне. Я пропустил сообщение об ошибке (хорошо скрытое). Проблема была

error: the following files have changes staged in the index: 

(скрытый в конце строки и сопровождаемый, возможно, сотнями файлов). Думаю, я забыл модификатор -f (также также забыл выручить при ошибке).

На самом деле, похоже, что нет причин использовать git rm вместо /bin/rm вместе с --tree-filter.


1 Я считал удаление мой вопрос, однако, это может спасти кому-то совсем немного времени.