C.4.3 Editinfo
The `editinfo' feature has been
rendered obsolete. To set a default editor for log
messages use the CVSEDITOR
, EDITOR
environment variables
(see section All environment variables which affect CVS) or the `-e' global
option (see section Global options). See Verifying log messages,
for information on the use of the `verifymsg'
feature for evaluating log messages.
If you want to make sure that all log messages look the
same way, you can use the `editinfo' file to
specify a program that is used to edit the log message.
This program could be a custom-made editor that always
enforces a certain style of the log message, or maybe a
simple shell script that calls an editor, and checks
that the entered message contains the required fields.
If no matching line is found in the `editinfo'
file, the editor specified in the environment variable
$CVSEDITOR
is used instead. If that variable is
not set, then the environment variable $EDITOR
is used instead. If that variable is not
set a default will be used. See Committing your changes.
The `editinfo' file is often most useful together
with the `rcsinfo' file, which can be used to
specify a log message template.
Each line in the `editinfo' file consists of a
regular expression and a command-line template. The
template must include a program name, and can include
any number of arguments. The full path to the current
log message template file is appended to the template.
One thing that should be noted is that the `ALL'
keyword is not supported. If more than one matching
line is found, the first one is used. This can be
useful for specifying a default edit script in a
module, and then overriding it in a subdirectory.
If the repository name does not match any of the
regular expressions in this file, the `DEFAULT'
line is used, if it is specified.
If the edit script exits with a non-zero exit status,
the commit is aborted.
Note: when CVS is accessing a remote repository,
or when the `-m' or `-F' options to cvs
commit
are used, `editinfo' will not be consulted.
There is no good workaround for this; use
`verifymsg' instead.