pre-commit hooks and $Id$ banners?

[Jamie Wilkinson]

This one time, at band camp, Matthew D. Fuller wrote:
>With CVS, you don't get the choice; all you can talk about is the
>individual files, and at best you can try and reconstruct a tree from
>that.  That's a Bad Thing, and we don't want to recreate that.  OTOH,
>we don't want to go the other way, and force you to try and use the
>tree info to try and find out about the individual file, either.
>
>The simplest and most obvious case where we care about one file is
>something like:
>% tail -1 foo.html
>    <p>Last modified: $Date$</p>
>
>Other cases can involve files that often get flung around on their
>own; they may be VCS'd together with other files, but often I may want
>to look at just one file, and know when it's from.  I deal with a
>number of cases where people edit the code outside the VCS, and it's
>left to me to try and merge the changes in to the latest version.
>Too, they may well mix pieces of tree revisions; having the info in
>each file is the only way I can be [reasonably] sure to have it and
>that it's maybe correct; an external file wouldn't cut it.
>
>Now, if the tree is at revision 123, and the file was last modified at
>111, in theory at least it's just as valid for it to give the tree rev
>(123) as the file's rev (111), and we may want the capability to do
>both, but I LIKE having the filerev in the keyword.  I can tell at a
>glance from a CVS $Id$ who last changed it and when it was last
>changed.  If all I had was a tree rev, I'd have to go poke through the
>log and file the last mod before that tree rev, which would be
>difficult to do precisely (or programmatically).

Seems to me that all the information you want here is available
programattically through bzrlib.  If one needs this information from a
tree for a build, they can extract it easily enough.

I still maintain that it's not bzr's place to be fiddling with the contents
of files under its control.