Re: avoiding rejects

[Dan Aloni <da-x@monatomic.org>]

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