Как запустить код форматировщик над моим источником, не изменяя историю GIT?

голоса
-2

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

Существует мерзавец команда фильтра-ветвь, которая позволяет выполнить команду против каждого пересмотра начиная репо с начала времени.

git filter-branch --tree-filter '\
  npx prettier --write src/main/web/app/**/**.{js, jsx} || \
  echo Error: no JS files found or invalid syntax' \
  -- --all

Это будет длиться вечно , чтобы запустить это и на самом деле я не забочусь о прошлом. Я просто хочу , чтобы форматировать мастер ветви идти вперед без изменения права собственности на каждую линию. Как я могу это сделать? Я пытался играть с rev-listна концах и другие фильтры типов , но он по- прежнему не работает. Там должна быть способом форматирования кодового при сохранении информации об авторе каждой строки.

Задан 27/11/2018 в 15:13
источник пользователем
На других языках...                            


2 ответов

голоса
1

То, что вы пытаетесь сделать, это невозможно. Вы не можете, в какой-то момент времени, измените строку кода, и все же есть отчет GIT, что самые последние изменения в этой строке кода является то, что произошло до этого момента времени.

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

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

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

Как вы уже отмечали, простой способ сделать это с помощью filter-branchбыло бы очень много времени. Есть вещи , которые вы можете сделать , чтобы ускорить его (как придав ему для электронного диска своего рабочего дерева), но это tree-filterи включает в себя обработку каждой версии каждого файла.

Если вы сделали какой - то предварительной обработки, вы могли бы быть несколько более эффективным. Например, вы могли бы быть в состоянии предобработку каждой BLOBв базе данных и создать отображение (где TREEсодержится BLOBX, замените его BLOBY), а затем использовать index-filterдля выполнения замены. Это позволило бы избежать все проверки и добавления операции, и это позволило бы избежать неоднократно повторно форматировать те же файлы кода. Так что экономит много I / O. Но это нетривиальная вещь , чтобы установить, и все еще может быть много времени.

(Это можно записать более специализированный инструмент , основанный на этом же принципе, но AFAIK никто не написал один. Существует прецедент , что более специализированные инструменты могут быть быстрее , чем filter-branch...)

Даже если вы пришли к решению, которое будет работать достаточно быстро, иметь в виде, что история переписаны будет тревожить все ваши реф. Как и любая история переписывание, это будет необходимо для всех пользователей РЬЕГО обновить свои клоны - и что-то в этом подметание, как я рекомендую сделать это, бросить клоны, прежде чем начать переписывать и повторно клон позже.

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

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

Выполните переформатирование в новой фиксации. Если вам нужно использовать git blame, и это указывает вам на коммит , где переформатирование произошло, а затем следить за запуском git blameснова на переформатирования фиксации родительская.

Да, это отстой. Какое-то время. Но данная часть истории, как правило, становится менее важным, как возраст, так что оттуда просто пусть проблема постепенно уменьшаться в прошлое.

Ответил 27/11/2018 в 15:56
источник пользователем

голоса
0

Там должна быть способом форматирования кодового при сохранении информации об авторе каждой строки.

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

Так что это идея, но есть некоторые большие причины, которые вы не должны делать это:

  1. Перебазирования общей ветви является плохой идеей. Тот факт , что вы даже заботитесь о сохранении авторства изменений , вероятно , означает , что существует целый ряд людей , активно работающих над кодом. Если вы идете и перебазироваться мастер ветви, а затем каждый вилка или клон вашего репозитория будет иметь мастер - ветвь с древней историей, и это неизбежно вызывает смятение и боль , если вы не очень осторожны , об управлении процессом и убедившись, что все знают о том, что вы делаете , и обновляет их копии надлежащим образом . Лучший подход, вероятно , будет не перебазироваться мастер, но вместо того, чтобы объединить совершающее от мастера в вашей отрасли. Тогда есть все начинают использовать новую ветку вместо master.

  2. Слияние конфликтов. В переформатированиях всех кодовые, вы , вероятно , будете вносить изменения в большом количество линий почти в каждом файле. При слиянии последующих фиксаций, является ли это с помощью rebaseили merge, вы , вероятно , имеете большое количество конфликтов , чтобы решить. Если взять подход я предложил выше и объединить коммиты из мастера в новую ветвь вместо перебазирования, то это будет легче разрешить эти конфликты упорядоченным образом , потому что вы можете объединить несколько фиксаций в то время , пока вы не поймаете вверх.

  3. Неполное решение. Вы будете иметь , чтобы выяснить , где в истории вы хотите , чтобы вставить операцию переформатирования. Чем дальше вы идете, тем больше вы будете сохранять авторство изменений, но тем больше работы она будет сливаться в последующих изменениях. Таким образом , вы , вероятно , до сих пор в конечном итоге с большим количеством кода , где ваш переформатирование совершившим является последним изменением.

  4. Ограниченная польза. Вы никогда не потеряете информацию об авторстве в git- это просто инструменты , как правило , только показать , кто сделал самое последнее изменение. Но вы все еще можете вернуться назад и посмотреть на предыдущих фиксаций и вырыть через всю историю любой части кода, в том числе , кто сделал это. Так что единственное , что вставив переформатирование операции в историю действительно покупает у вас есть удобство посмотреть , кто изменил некоторый кусок кода без дополнительного шага вернуться к более ранней фиксации.

  5. Это нечестно. Когда вы переписать историю отрасли, вы изменяете фактическую запись о том , как код изменился с течением времени, и это может создать реальные проблемы. Давайте представим , что ваше переформатирование не совсем так , как несущественное вы имеете в виду, чтобы это были, и при этом переформатировании вы на самом деле создать ошибку. Допустим, например, что вы вводите некоторое дополнительное пустое пространство в многострочных строки постоянная. Несколько недель спустя, кто - то наконец -то замечает проблему и идет искать причину, и это выглядит как изменение было принято полтора года назад (потому что там вы вставили переформатирование в историю). Но проблема кажется новой - это не проявляется в сборке, поставляемой два месяца назад, так что, черт возьми, происходит?

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

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

Ответил 27/11/2018 в 18:53
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more