What's wrong with changing * _defconfig when working with Linux kernel sources

Following the traces of my first publication, I want to make a short note about changing the i386_defconfig or x86_64_defconfig files included in the Linux kernel source package.



In the comments on that publication, users (in particular ValdikSS ) were interested in why not editing .config? On the scale of the comment, I could not give a detailed answer there.

So, let's start with the difference between .config and * _defconfig. Attentive user typing a team

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

can easily detect that the file difference is about 10 (!) times.

What does it do make *_defconfig? Actually nothing super special. Important actions are listed below:

• Removes options that are outdated or missing in the current kernel version.
• Builds a dependency tree for an option
• Applies default rules to all options that were specified in the default configuration and by dependencies
• Translates all this into a .config file

Therefore, it is not just a copy of the file.

Returning to editing the original version of * _defconfig. What are the benefits?

• Minimum changes that need to be made, the rest will be done for us by scripts
• You can always see the difference with a stable base ( git diff)

Disadvantages?

• Inconvenient in rare cases git bisect
• Need your own local brunch (which can be both an advantage and a disadvantage)

In the list I already hinted that the standard practice of editing files in Git involves creating your own brunch. There we accumulate our own changes. For me, the advantages outweighed the disadvantages, so I do not see anything reprehensible in editing * _defconfig.

What are your practices?