Как обработать широко распространенные изменения формата кода в репозитории мерзавца
В PHP 5 вещи, покрытые E_STRICT, не покрыты E_ALL, так для получения большей части информации, необходимо объединить их:
error_reporting(E_ALL | E_STRICT);
В PHP 5.4, E_STRICT будет включен в E_ALL, таким образом, можно использовать всего E_ALL.
можно также использовать
error_reporting(-1);
, который будет всегда включать весь ошибки. Который более семантически корректен как:
error_reporting(~0);
3 ответа
Вам также понадобится mergetool, который позволяет агрессивно игнорировать пробелы. p4merge делает это, и его можно бесплатно загрузить.
Я не знаю, как лучше всего бороться с некоторыми из наиболее агрессивных изменений, которые вы описываете, но ...
Параметр -w для git blame , git diff и других заставляет git игнорировать изменения в пробелах, так что вам будет легче увидеть реальные различия.
Я бы порекомендовал делать эти эволюции пошагово, в центральном репозитории Git (центральный, как в «общедоступной ссылке для всех остальных репозиториев»):
- отступ
- затем методы переупорядочения
- , затем переименование
- , затем ...
Но не «отступы-переупорядочивание-переименование -...- одна гигантская фиксация».
Таким образом, вы даете Git разумный шанс следовать изменения в модификациях рефакторинга.
Кроме того, я бы не стал принимать какое-либо новое слияние (полученное из другого репо), в котором не применялся такой же рефакторинг, перед тем, как отправить их код.
Если применение процесса форматирования приводит к каким-либо изменениям в извлеченном коде, вы можете отклонить его и сначала попросить удаленное репо соответствовать новым стандартам (по крайней мере, вытащив из репозитория, прежде чем делать какие-либо дополнительные действия).