Что плохого в изменении *_defconfig при работе с исходниками ядра Linux

По следам моей первой публикации хочу сделать небольшую заметку об изменении файлов i386_defconfig или x86_64_defconfig, входящих в поставку исходников ядра Linux.

В комментариях к той публикации пользователи интересовались, почему не редактировать .config? В масштабах комментария я не смог дать там развёрнутый ответ.

Так вот, начнём с того, в чём разница между .config и *_defconfig. Внимательный пользователь, набрав команду

wc -l .config arch/x86/configs/{i386,x86_64}_defconfig 

может легко обнаружить, что разница файлов примерно в 10 (!) раз.

Что же делает make *_defconfig? Собственно ничего супер особенного. Важные действия перечислим ниже:

• Удаляет опции, которые устарели или отстутствуют в текущей версии ядра
• Строит дерево зависимостей для опции
• Применяет правила по умолчанию ко всем опциям, которые были указаны в конфигурации по умолчанию и по зависимостям
• Транслирует это всё в файл .config

Таким образом это не просто копия файла.

Возвращаясь к редактированию исходной версии *_defconfig. Какие преимущества?

• Минимум изменений, которые нужно вносить, остальное за нас сделают скрипты
• Всегда можно увидеть разницу со стабильной базой (git diff)

Недостатки?

• Неудобно в редких случаях делать git bisect
• Нужен собственный локальный бранч (что может быть как достоинством, так и недостатком)

В списке я намекнул уже, что стандартная практика редактирования файлов в Git’е подразумевает создание собственного бранча. Туда мы накапливаем собственные изменения. Для меня достоинства перевесили недостатки, поэтому я не вижу ничего предосудительного в том, чтобы редактивать *_defconfig.

Каковы ваши практики?

ссылка на оригинал статьи http://habrahabr.ru/post/252391/