Consider the following patch:

    root@dali:/etc# darcs cha --max=1 -v
    Thu Jul 22 13:29:46 EST 2010  twb
      * committing changes in /etc after apt run

      Package changes:
      -etckeeper 0.47
      +etckeeper 0.48
        hunk ./.darcsignore 3
        -^(./)?console-setup/cached\.kmap\.gz$
        +^(./)?console-setup/cached.kmap.gz$
        hunk ./.darcsignore 5
        -^(./)?(mailcap|resolv\.conf|nologin)$
        -^(./)?readahead\.d/(custom\.)?(early|later)(\.sorted)?$
        +^(./)?(mailcap|resolv.conf|nologin)$
        +^(./)?readahead.d/(custom.)?(early|later)(.sorted)?$
        hunk ./.etckeeper 709
        +maybe chmod 755 './etckeeper/vcs.d/50vcs-cmd'
        hunk ./etckeeper/commit.d/50vcs-commit 52
        -   if [ -n "$HGUSER" ]; then
        +   if [ -z "$HGUSER" ]; then
        adddir ./etckeeper/vcs.d
        addfile ./etckeeper/vcs.d/50vcs-cmd
        hunk ./etckeeper/vcs.d/50vcs-cmd 1
        +#!/bin/sh
        +set -e
        +
        +# check whether we can locate the vcs binary
        +if [ -n "$VCS" ] && which "$VCS" > /dev/null; then
        +        # pass commands to the VCS application
        +        $VCS "$@"
        +else
        +   echo "error: VCS ($VCS) not set or not in PATH" >&2
        +   exit 1
        +fi
        changepref boringfile
        .darcsignore
        .darcsignore

At the bottom, you can see that darcs has dutifully recorded a no-op
change of the boringfile preference.  This is because etckeeper
assumes that "darcs setpref boringfile .darcsignore" is idempotent,
and runs it every time etckeeper is upgraded.

I wish a changepref to the current value didn't get recorded.

I guess it's fair enough that darcs relies on the value of 
_darcs/prefs/prefs just like it relies on the value of the pristine state 
for changepref.

The whole preferences system is a bit flaky and could use an overhaul.

See issue1805