Табуляция в пробелы GIT

#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 может это сделать. 😉