Как ДЕЙСТВИТЕЛЬНО показать журналы переименованных файлов с помощью git?

Я относительно новичок в git, раньше использовал Subversion.

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

git log --follow

в командной строке я могу видеть весь журнал переименований.

По словам Линуса Торвальдса, переключатель --follow - это угодник "SVN noob", серьезные пользователи git не используют его:

--follow - это полный взлом, предназначенный просто для удовлетворения бывших пользователей SVN, которые в любом случае ничего не знали о таких вещах, как отцовство или красивые графы ревизий.

Это не совсем фундаментально, но текущая реализация «--follow» на самом деле является средством быстрой предварительной обработки, прикрепленным к логике обхода ревизий, а не чем-то действительно целостным.

Он в буквальном смысле был разработан как приятель «SVN noob», а не как «настоящая функциональность git». Идея заключалась в том, чтобы уйти от (сломанного) мышления, которое переименовывает материю в большой картине.

Мой вопрос : как хардкорные пользователи git среди вас получают историю файла, когда он был переименован? Как это сделать «настоящий»?

Я думаю, что основная идея, стоящая за точкой зрения Линуса, заключается в том, что - и отнеситесь к этому с долей скепсиса - хардкорных пользователей git никогда не волнует история «файла». Вы помещаете контент в репозиторий git, потому что контент в целом имеет значимую историю.

Переименование файла - это небольшой частный случай перемещения «содержимого» между путями. У вас может быть функция, которая перемещается между файлами, которые пользователь git может отслеживать с помощью «кирки» функционально (например log -S).

Другие изменения "пути" включают объединение и разделение файлов; git на самом деле не волнует, какой файл вы считаете переименованным, а какой - скопированным (или переименованным и удаленным), он просто отслеживает полное содержимое вашего дерева.

git поощряет мышление «целым деревом», в то время как многие системы управления версиями сильно ориентированы на файлы. Вот почему git чаще обращается к «путям», чем к «именам файлов».

У меня точно такая же проблема, с которой столкнулись вы. Несмотря на то, что я не могу вам ответить, я думаю, вы можете прочитать это письмо, которое Линус написал еще в 2005 году, оно очень уместно и может дать вам подсказку о том, как справиться с проблемой:

… Я утверждаю, что любой SCM, который пытается отслеживать переименования, принципиально нарушен, если только он не делает это по внутренним причинам (т.е. для обеспечения эффективных дельт), именно потому, что переименования не имеют значения. Они вам не помогают, и в любом случае это не то, что вас интересовало .

Важно найти «откуда это взялось», и архитектура git действительно справляется с этим очень хорошо - намного лучше, чем что-либо еще. ...

Я нашел ссылку на это сообщение в блоге, которое также может быть полезно для вас, чтобы найти жизнеспособное решение:

В сообщении Линус рассказал, как идеальная система отслеживания контента может позволить вам узнать, как блок кода принял текущую форму. Вы должны начать с текущего блока кода в файле, вернуться в историю, чтобы найти фиксацию, которая изменила файл. Затем вы проверяете изменение фиксации, чтобы увидеть, модифицирован ли ею интересующий вас блок кода, поскольку фиксация, изменяющая файл, может не касаться интересующего вас блока кода, а только некоторых других частей файл.

Когда вы обнаружите, что перед фиксацией в файле не было блока кода, вы исследуете фиксацию глубже. Вы можете обнаружить, что это одна из многих возможных ситуаций, в том числе:

1. Коммит действительно представил блок кода. Автор коммита был изобретателем той классной функции, за которой вы искали ее происхождение (или виновной стороной, которая внесла ошибку); или
2. Блок кода не существовал в файле, но пять его идентичных копий существовали в разных файлах, и все они исчезли после фиксации. Автор коммита реорганизовал дублированный код, добавив единственную вспомогательную функцию; или
3. (как особый случай) Перед фиксацией файл, который в настоящее время содержит блок кода, который вас интересует, сам по себе не существовал, но существовал другой файл с почти идентичным содержимым, и блок интересующего вас кода, вместе со всем остальным содержимым файла, существовавшим тогда, действительно существующим в этом другом файле. Он исчез после фиксации. Автор коммита переименовал файл, внося в него незначительные изменения.

В git окончательный инструмент отслеживания контента Линуса еще не существует в полностью автоматизированном режиме. Но большинство важных ингредиентов уже доступны.

Пожалуйста, держите нас в курсе вашего прогресса в этом вопросе.

Я заметил, что большинство графических интерфейсов git и плагинов IDE, похоже, не могут отображать историю файла, если файл был переименован.

Вы будете рады узнать, что некоторые популярные инструменты пользовательского интерфейса Git теперь поддерживают это. Доступны десятки инструментов пользовательского интерфейса Git, поэтому я не буду перечислять их все, но, например:

• SourceTree при просмотре журнала файлов имеет флажок "Следить за переименованными файлами" в левом нижнем углу.
• TortoiseGit имеет флажок "следовать переименованию" в окне журнала в левом нижнем углу.

Дополнительная информация об инструментах Git UI:

• http://git-scm.com/downloads/guis
• https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools

Примечание: git 2.9 (июнь 2016 г.) немного улучшит "глючный" характер git log --follow:

См. Commit ca4e3ca (30 марта 2016 г.) Седера Габора ( szeder) .
^{(Объединено Junio ​​C Hamano - gitster- в коммите 26effb8 , 13 апреля 2016 г.)}

diffcore: исправить порядок итерации идентичных файлов при обнаружении переименования

Если два пути ' dir/A/file' и ' dir/B/file' имеют идентичное содержимое и родительский каталог переименован, например, ' git mv dir other-dir', то diffcoreсообщает о следующих точных переименованиях:

renamed:    dir/B/file -> other-dir/A/file
renamed:    dir/A/file -> other-dir/B/file

(обратите внимание на инверсию здесь:, B/file -> A/fileи A/file -> B/file)

Хотя технически это нормально, это сбивает с толку не только пользователя, но и команды git, которые принимают решения на основе информации о переименовании, например, git log --follow other-dir/A/file«следует dir/B/file» после переименования.

Такое поведение является побочным эффектом фиксации v2.0.0-rc4 ~ 8 ^ 2 ~ 14 ( diffcore-rename.c: упрощение поиска точных переименований, 2013-11-14): хэш-карта, хранящая источники, возвращает записи из того же сегмента, то есть источники, соответствующие текущему месту назначения , в порядке LIFO.
Таким образом, итерация сначала проверяет ' other-dir/A/file' и ' dir/B/file' и, обнаружив идентичное содержимое и базовое имя, сообщает точное переименование.

В Linux я убедился, что SmartGit и GitEye могут отслеживать переименования при отслеживании истории конкретного файла. Однако, в отличие от gitk и GitEye, SmartGit показывает отдельное представление файла и представление репозитория (которое содержит структуру каталогов, но не список файлов, содержащихся внутри).