you are working on the assumption that patches are discrete units
what i'm proposing is a tool to allow for the inspection of a "patch" from a
number of different angles. look i'm sure this must be what we all have done at
some time in the past. a patch comes in for "a piece of software". do you apply
it blindly? no. first you probably have a look at it with a text editor or a
pager. ok, so the patch touches 97 files. what did the author say at the top?
this patch does blah-di-blah blah blah. ok, so the author say it does such and
such. in that case it should only be touching some set of files. lets have a
look at what files it touches. grep '^diff' patch. well now, it indeed touches
the set of files the author said it should, but wait here! why is it touching
/etc/passwd.
ok so the patch looks ok! does it apply cleanly. well lets have a try (because
it is the only way to find out). better keep a record of what it does.
script foo
patch -p1 <mumble
^D
grep rej foo
so 245 hunks failed eh!
no so good
mailx luser-author@nowheresville.com
Subject: that piece of crap patch that you sent me!
blah blah blah
see the kind of scenario i'm painting. a tool that would provide the answers to
such questions (like an oo code browser if you will) would make the job easier
for any person in the code patching hierarchy of "major project X"
consider this to be a very poor attempt at a "use case" analysis of one of the
problems i see facing the linux kernel hacking community (of which i'm but a
poor humble observer)
hell i subscribe to the list mainly to see who's pulling strips off whom (half
in jest)
regards
-- simon- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/