http://darcs.net/manual/node7.html#SECTION00712000000000000000  
mentions DARCS_FILES and DARCS_PATCHES available in posthooks with  
some commands. They both seem empty in a prehook for record or apply.

There is some previous discussion here: http://webcache.googleusercontent.com/search?q=cache:sYDpL4xy0-MJ:irclog.perlgeek.de/darcs/2008-12-04+darcs+prehook&cd=4&hl=en&ct=clnk&gl=us 
  .

Unless there's a real security objection that I missed, I think eg  
DARCS_PATCHES definitely belongs in the record prehook's environment,  
so that you can have eg a spam-rejecting prehook. (Useful for gitit  
wiki edits, and wiki editors accidentally re-pushing obliterated spam  
patches.)

Also these environment variables should be made consistent across  
commands and hooks and/or their availability documented.

If I understand correctly, prehooks are run before any part of the 
command including the interactive mode.  So a hypothetical spam-
rejecting prehook for record would be tricky exactly as described.

But the apply prehook could be useful.

Also, not a technical blocker, but perhaps we should avoid expanding the 
use of the posthook environment variable mechanism until we've got 
issue1766 sorted

Also, as a principle, separate issues should be separate tickets if 
there's any reason to believe the two may be resolved/discussed 
independently of each other.

Yes, you're right of course. Currently prehooks are run quite early, 
before darcs has figured out anything about files and patches, so their 
awareness of what's going on is very limited.

So this is an enhancement wish. I'd like more information to be made 
available to prehooks, by whatever mechanism, so that they can be 
smarter. This would let you eg set up automated acceptance criteria for 
incoming patches.

As a use-case: I was thinking I could use a "prehook" to whitespace 
clean-up in the files about to be recorded, but I see now that I can't do 
that, because prehook runs so early, that the files about to be involved 
in the patch aren't available.