bzr-gtk should not try to expand config options where none are expected

[GuilhemBichot]

This is likely a consequence of:
https://code.launchpad.net/~vila/bzr/config-expand-options.
After upgrading to version 2.6, we get errors like this:

bzr commit -m 'fix for {Write,Update}_row_class'
Committing to:...
modified README
Committed revision 4819.

bzr uncommit
 4819 Guilhem Bichot 2013-02-25
      fix for {Write,Update}_row_class

The above revision(s) will be removed.
Uncommit these revisions? ([y]es, [n]o): yes
You can restore the old tip by running:
  bzr pull . -r revid:<email address hidden>

bzr gci
bzr: ERROR: Option Write,Update is not defined while expanding "fix for {Write,Update}_row_class

What happens:
* "uncommit" has saved the commit comments of the uncommitted revision into an option in branch.conf, so that they can be picked up again by a later "bzr gci"
* "gci" tries to read the option, but this now uses expansion (starting from version 2.6), and it turns out that {Write,Update} is recognized as syntax for expansion. Then it fails.

Apart from not using {} in our comments, is there a workaround? Will this be fixed in bzr or in bzr-gtk?

bzr-gtk is gtk 0.104.0dev. bzr 2.6b2.

[John A Meinel (jameinel)]

My thought would be to have an easy way to make sure strings are properly quoted when writing out the data, possibly via a change in either bzr-gtk or in bzr.

[Vincent Ladeuil (vila)]

The fix is to disable option expansion for the commit message.

Requiring users to escape the expansion here makes no sense. If expansion is needed it can be performed to produce an already expanded message for commit so there is no need to care about config options in the commit message.

Most probably bzr-gtk is the culprit here, bzr doesn't define the commit message as a config option AFAIK.

[Vincent Ladeuil (vila)]

Post-fix:

@Guilhem: Thanks for the precise diagnostic. Indeed the branch you pointed introduced the issue (by turning expansion on by default). Yet, the most common use case for options is to allow references to other options. There are only a few exceptions: templates for which expansion is generally specific and here, bzr-gtk storing values where option references make no sense (the feature is to restore the exact value that was stored).

The fix is compatible with bzr-2.5