[only RFC, not merge] Second implementation of the "commit templates" feature

Adeodato Simó dato at net.com.org.es
Mon Aug 14 02:47:23 BST 2006


* Adeodato Simó [Thu, 10 Aug 2006 21:43:25 +0200]:

> only John's comment about StringIO/bzrlib.user_encoding() is left
> temporarily unaddressed, I believe

Ah, I understand the involved issues now. Not that it helps much,
though, since now I understand the trickyness of the situation as well. ;-)

Basically, it boils down to:

  - commit templates should provide their infotext() as an unicode()
    object, since that's what edit_commit_message() wants.

  - however, not all commit templates are able to do that. In particular, 
    the "diff" bit can't, because it can't really assume that the contents
    are in bzrlib.user_encoding (cmd_diff has encoding_type = 'exact',
    not 'strict').

Because of the above:

  - commit templates will probably need an encoding_type member, like
    Command (because of this I'll probably move _CommitTemplateBit to
    being a public class, and have register_commit_template receive an
    instance of it instead of a function, or something).

  - I was initially happy to see that I could make use of
    edit_commit_message() without any API breaking. However, it now has
    to support receiving str() instead of unicode(), and it's going to
    end up ugly, so I'm thining I'll refactor code in edit_commit_message()
    into CommitTemplateFile or so, and will leave a dummy deprecated
    implementation of edit_commit_message(), as I did with
    make_commit_message_template().

Suggestions or comments always welcome.

Cheers,

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
                                             Listening to: Mecano - Dalí





More information about the bazaar mailing list