#git
#git
Вопрос:
Я работаю над проектом с несколькими другими разработчиками. Не все используют одну и ту же IDE. Недавно я понял, что некоторые части кода имеют отступы с помощью табуляции, а некоторые — с пробелами. Все выглядит нормально при использовании tab = 4 пробела для отображения кода, но с другими настройками это становится действительно запутанным.
Мы используем git в качестве VCS. Есть ли какой-нибудь способ переформатировать весь код в репозитории, зафиксировать эти изменения И каким-то образом сохранить «информацию о вине»?
Ответ №1:
Нет, это невозможно без перезаписи истории.
Самое простое и удобное для разработчика решение (которое, однако, не сохранит информацию о виноватых) — это исправление всех проблем с пробелами за один коммит, а затем настройка git на отклонение коммитов, добавляющих смешанные пробелы.
Если перезапись истории не является для вас проблемой (например, потому что вы можете попросить всех разработчиков удалить свои локальные ветки и получить перезаписанные), вы, вероятно, могли бы использовать git filter-branch
для исправления пробелов во всех коммит. Это не приведет к новой фиксации и, таким образом, гарантирует git blame
отображение правильной информации после изменения.
Комментарии:
1. Я полагаю, что ваш ответ аналогичен ответу @AndrejsCainikovs, поскольку его ответ гарантировал бы, что новая история будет написана «нейтральным» способом, а ваша «старая» история соответствует новому требованию. Переписывание истории для замены пробелов не должно быть слишком плохим, в
diff
любом случае их можно легко исключить.2. Переписывание истории всегда плохо, если вы не можете либо заставить каждого отдельного пользователя , который клонировал ваш репозиторий, выполнить точно такое же переписывание (легко, если у вас есть скрипт, и им просто нужно вызвать его с помощью git-filter-branch), либо выбросить их ветки на основе старой истории.
3. вы также можете направить их на выборку нового материала и умело перебазировать поверх него. Мы говорим об изменениях пробелов там… Таким образом, это намного проще, чем если бы мы говорили о больших изменениях.
4. Я думаю, я мог бы пойти с переписыванием истории. Команда не такая уж большая. Однако, что бы произошло, если бы кто-нибудь не переписал историю (или не клонировал репозиторий еще раз) и не попытался отправить в origin?
5. Он получит сообщение об ошибке, если не нажмет кнопку using
--force
(в этом случае он отменит перезапись истории в удаленном репозитории).
Ответ №2:
Вы могли бы написать свой собственный скрипт, который заменяет табуляции нужным количеством пробелов (4 в вашем случае), и поместить его в .git/hooks/pre-commit
.
Комментарии:
1. Уверен, что этого не будет. То, что вы зафиксировали, останется. Но вы можете решить это одним отдельным коммитом 🙂
2. Что затем делает git-blame бесполезным, если вы явно не укажете ему использовать любую версию, которая была до фиксации пробела 😉
3. @ThiefMaster На самом деле, в git blame есть опция -w, которая игнорирует изменения пробелов.
4. Могу ли я установить эти перехваты в центральном репозитории, чтобы они были клонированы / извлечены с изменениями?
5. К сожалению, нет. Но вы могли бы создать перехват, который проверяет полученный коммит, если они вводят неверные пробелы, и в этом случае отклонить отправку.
Ответ №3:
Простой скрипт bash может заменить каждую табуляцию на 4 пробела, но вам придется использовать его перед каждой фиксацией…
Или посмотрите на настройки разных ide, чтобы использовать табуляцию вместо пробелов. Я знаю, что emacs может это сделать. 😉