On Tue, May 5, 2009 at 2:43 AM, Robby Workman <rworkman@xxxxxxxxxxxxx> wrote: > Jon and list, > > Feel free to poke fun at me if I did something wrong, but I'm new > with git. I let github generate a pull request there, but there > was no feedback at all on whether it was successful, so I have no > idea if it actually sent one. Anyway, here's the link and diffstat: > > git://github.com/rworkman/module-init-tools.git > > FAQ | 11 +-- > Makefile.am | 3 +- > README | 24 ++--- > doc/depmod.conf.sgml | 73 +++++++------ > doc/depmod.sgml | 119 ++++++++++----------- > doc/insmod.sgml | 32 +++---- > doc/lsmod.sgml | 19 ++-- > doc/modinfo.sgml | 97 +++++++++-------- > doc/modprobe.conf.sgml | 208 ++++++++++++++--------------------- > doc/modprobe.sgml | 210 ++++++++++++++++++------------------ > doc/modules.dep.sgml | 39 ++++---- > doc/rmmod.sgml | 62 +++++------ > generate-modprobe.conf | 281 > ------------------------------------------------ If you look at "git-log generate-modprobe.conf", you see it's had multiple patches submitted this year. Now, given the history of m-i-t development, it's possible that the patches were just extremely delayed and no-one will care if you delete it. But I think you should CC the patch authors and find out why they cared enough to submit them :-). > install-with-care | 10 +-- > modprobe.devfs | 62 ----------- > 15 files changed, 409 insertions(+), 841 deletions(-) > Changed backticks to $() command substitution. Please note the reason for this in the changelog, I can't read your mind. > doc/rmmod.sgml > + <para><command>rmmod</command> is a trivial program to remove a module > + from the kernel. Most users will want to use > - </citerefentry> instead, with the <option>-r</option> option. > + </citerefentry> instead, perhaps with the <option>-r</option> option. ? If you're looking at using rmmod, you want to remove the module. If you coose to use modprobe instead, why do you only "perhaps" want to use -r? > doc/depmod.conf.sgml - For example, it is possible to override the priority of - an updated test module called <command>kmp</command> by - specifying the following command: "override kmp * extra". - This will ensure that any matching module name installed - under the <command>extra</command> subdirectory within - /lib/modules (or other module location) will take priority - over any likenamed module already provided by the kernel. + For example, it is possible to override the priority of an + updated test module called <command>kmp</command> by specifying + the following command: "override kmp * extra". This will ensure + that any matching module name installed under the + <command>extra</command> subdirectory within /lib/modules (or + other module location) will take priority over any likenamed + module already provided by the kernel. This is a random snippet pasted from the GitHub interface; it's probably replaced tabs with 8 spaces. This looks like you edited with 4 spaces to the tab, and replaced most existing spaces with tabs, or something. And changed the word wrapping. And it looks like the original words are unchanged? It looks to me like the files are supposed to be 8 spaces to the tab, just like the C code. I.e. some of them switch randomly between spaces and tabs, and it seems to look best with 8 spaces to the tab. So I think you need to try harder to follow the existing convention. That would make it much easier to review these changes. If you want to faff around with whitespace and word-wrapping, please do a complete conversion of all files to whatever style you're advocating, and do it in a _separate_ commit to the actual updates. Talking of separate commits, it would be nice to avoid splitting the commits by file. We can all read multi-file diffs; I don't think you would have lost anything by e.g. committing all the SGML files at the same time. That would avoid an ugly history with 8 or so commits with the same name :-). Thanks Alan -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
