What is wrong with changing * _defconfig when working with Linux kernel sources

In the wake of my first publication, I want to make a small note about the change in the i386_defconfig or x86_64_defconfig files included in the Linux kernel source.



In the comments to the publication, users (in particular, ValdikSS ) were interested, why not edit .config? To the extent of the commentary, I could not give a detailed answer there.
')
So, let's start with the difference between .config and * _defconfig. Attentive user typing command

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

can easily find that the difference of files is about 10 (!) times.

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

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

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

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

• The minimum of changes that need to be made, the rest for us will make scripts
• You can always see the difference with a stable base ( git diff )

Disadvantages?

• It is inconvenient in rare cases to do git bisect
• You need your own local brunch (which can be both advantage and disadvantage)

In the list, I have 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 virtues outweighed the flaws, so I see nothing wrong with editing * _defconfig.

What are your practices?