On Tue, Jul 10, 2007 at 12:44:22PM -0700, Andrew Morton wrote: > > There are many situations where patching the kernel involves adding a new > item to a list, such as: > > - adding a makefile line > - adding a new #include > - adding a new Kconfig entry > - adding a new PCI ID > - adding a record to feature-removal.txt > - adding a new sysctl table entry > - etc > > Of course, everyone just sticks the new entry at the end of the existing > entries. This strategy carefully maximises the opportunity for patch > rejects and leads to unhappiness. > > Most of these lists are unordered anyway, so inserting the new item at a > randomly-chosen position is a better approach than just appending it.
AFAIK some Kconfig entries do have some importance to order (take kernel/Kconfig.hz for example, though it's not a good one, not long enough). I think that random insertions can hurt on the readability side. So, here's a list of more ways to discuss: 1. How about adding a context-aware logic to the merging process? (i.e, project-specific "plugins") That is, beside the regular 3-line context, the merging logic can be a aware of particular file formats, whether it's a Kconfig tree-like structure or list of lines all starting with a prefix of '#include'. 2. Alternatively, these special one-liner diff hunks can be generated with smaller context space (2, 1, or even no lines). This means instead of adding context-awareness to the merger process, add context-awareness to the diff generator. The other 'more complex' code modifications hunks must remain with a context of 3 lines. 3. Another option is to come up with file formats that have '3 space lines' dilimeters between items (it wouldn't make sense for #include, but for PCI IDs it might be worth it). -- Dan Aloni XIV LTD, http://www.xivstorage.com da-x (at) monatomic.org, dan (at) xiv.co.il - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
