Для этого нет распространенного инструмента, поэтому вам придется написать свой собственный. Я написал бы сценарий Bash, который вызывает indentс различными параметрами, чтобы создать большое количество альтернативных версий исходного исходного файла, а затем находит «лучший» diffвывод для каждой альтернативной версии, где «наилучшим» может быть просто наименьшее количество измененных строк. ,
Мой опыт показывает, что вы можете разделить проблему, если знаете, кто написал оригинальный код. Программисты склонны принимать долгосрочные привычки форматирования, которые отличаются от программиста к программисту.
Вы должны ожидать, что даже в лучших случаях indentвводимые различия сделают svn / git blame бесполезным. Это, вероятно, заставит вас либо принять одну конкретную indentполитику для всего кода и запустить новый репозиторий с автоматически отформатированным кодом, либо просто отказаться от всей идеи. Хранилище с несколькими различными indentполитиками, вероятно, вызовет больше путаницы и ухудшения, чем пользы.
Если вы работаете над новым кодом, а не просто вносите небольшие изменения в существующий код, то лучше всего будет требовать от всех участников использования определенной политики indentили astyleполитики перед отправкой кода. Вы также можете сделать это автоматически, используя хуки для фиксации SVN / GIT, но это может вызвать ошибки компиляции или даже ошибки в редких случаях. Если вы работаете в организации и не запускаете онлайн-проект, в котором вы являетесь привратником, вам понадобится менеджер с достаточными полномочиями для реализации политики, поскольку большинство программистов уже знают из многолетнего опыта, что их собственное форматирование является единственным правильный путь и все остальные форматирования недопустимы.