Clang форматирует весь код с сохранением истории git

У меня есть проект с богатой историей git от нескольких пользователей, он никогда не форматировался автоматически, и я хотел бы запустить на нем clang-format. Важно сохранить историю git.

Некоторые примеры того, что я имею в виду.

Когда был блок кода от Джо, а затем «a + b» было преобразовано в a + b. Он остается в линии Джо в git blame.

Когда был

void foo()
{
    return k;
}

и он был отформатирован в

void foo() { return k; }

Он по-прежнему остается кодом Джо.

и Т. Д.

Какие-нибудь известные решения?

Что вы имеете в виду под сохранением истории?

Matthieu Brucher 03.01.2019 11:20

Что заставляет вас думать, что вы теряете историю git из-за ее автоматического форматирования? Вы имеете в виду, что вы больше не можете git blame так легко?

Max Langhof 03.01.2019 11:20

Вы смотрели git filter-branch? Это приведет к потере SHA1 ...

Botje 03.01.2019 11:24

Пожалуйста, посмотрите обновление.

Yuki 03.01.2019 12:25
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
1
4
956
2

Ответы 2

По сути, у вас не может быть обоих способов (то есть с сохранением истории и оптовым автоматическим форматированием), но у вас есть несколько вариантов.

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

2) Вы также можете просто применить форматирование как новую фиксацию (одиночную, огромную), но это затруднит использование git blame.

3) Вы также можете применять автоматическое форматирование на ходу, поскольку файлы изменяются во время разработки. Это будет иметь несколько меньшее влияние, но тоже не идеально.

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

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

  2. Перепишите всю историю, индивидуально форматируя каждую фиксацию. Это делает любые ссылки на хэши коммитов перед перезаписью и т. д. Недействительными, но дает вам чистый git blame / log. Для этого нужна магия с использованием (возможно, низкоуровневых) команд git. Или «простая» «интерактивная» перебазировка, при которой вы вносите поправки в каждый коммит с изменениями форматирования (хотя сохранение исходного коммиттера может вызвать некоторую дополнительную магию).

Последний вариант - исправить код по мере его фиксации. Это приводит к ужасному беспорядку стилей в одном файле и ничего не помогает.

Другие вопросы по теме