Re: I'm missing isofs.h

PB> Actually, I can't; the patch generator is not on par with mine yet. PB> It does not show modes and does not indicate file adds/removals by PB> /dev/null - basically, I need something cg-patch can eat (and it should PB> be backwards compatible). I think throwing the sha1 hashes away will not PB> harm; I got used to the Index: field and === marker, but I don't care if PB> I loose it.

I've looked at what cg-Xdiffdo does. From the above paragraph, I sense that it does more than what cg-patch requires, so I took a look at cg-patch, too.

Can you help me verify if I understand the requirements cg-patch has on its input correctly?

 - Follow the convention of showing newly added files with
   "--- /dev/null" and removed files with "+++ /dev/null";

 - Label matches this Perl regexp:

     m|^(---|\+\+\+)\s+[^/]+\/(\S+)\s+.*mode:([0-7]{3,}).*/|

   and you only care about sign ($1), filename ($2) and mode ($3).

To illustrate, cg-Xdiffdo generates something like:

 (modified files)
 --- FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF/fs/ext3/Makefile  (mode:0644)
 +++ EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE/fs/ext3/Makefile  (mode:0664)

 (deleted files)
 --- FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF/fs/ext3/Makefile  (mode:0644)
 +++ /dev/null  (tree:EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE)

 (added files)
 --- /dev/null  (tree:EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE)
 +++ FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF/fs/ext3/Makefile  (mode:0644)

but they could be like the following to satisfy cg-patch:

 (modified files)
 --- a/fs/ext3/Makefile  (mode:0644)
 +++ b/fs/ext3/Makefile  (mode:0664)

 (deleted files)
 --- a/fs/ext3/Makefile  (mode:0644)
 +++ /dev/null

 (added files)
 --- /dev/null
 +++ b/fs/ext3/Makefile  (mode:0644)

Is my understanding correct? If so it should not be too much work to generate something like it from within the builtin stuff.

Provided if that is what the kernel folks can live with (I do see why the tool wants the mode bits, but it is unusual to see non-timestamp strings after filenames).

Linus & Andrew, is the above (second) format acceptable for the kernel work?