qbzr does not use commit message hooks

This is likely not currently possible because qbzr shows its commit dialogue before creating the Commit object

Jonathan: that's right. I've chatted with Robert maybe or some other core dev and thay insist we have to create Commit object to get template message and then discard it. But this is going against qbzr/qcommit architecture. What if user changes the files selected for commit? If commit template uses list of files to commit then when user changes the list of files we need to re-build template? Very quickly things will become very complex to handle.

I've added bzr core to this bug report, because maybe it's worth to rethink how commit templates are generated by bzr, so they could be much easier to be used by GUI clients.

If you'll ask me then I say that I don't like the idea of creating Commit object and then somehow abort it.

For reference, there was a discussion on the mailing list about this about 12 months ago. The thread starts here: <https://lists.ubuntu.com/archives/bazaar/2010q2/068315.html>. My suggestions in <https://lists.ubuntu.com/archives/bazaar/2010q2/068327.html> still look reasonable to me.

Andrew Bennetts пишет:
> For reference, there was a discussion on the mailing list about this
> about 12 months ago. The thread starts here:
> <https://lists.ubuntu.com/archives/bazaar/2010q2/068315.html>. My
> suggestions in
> <https://lists.ubuntu.com/archives/bazaar/2010q2/068327.html> still look
> reasonable to me.

Thank you for the reminder. I've extracted your thoughts from your mail
(last link):

qbzr apparently wants to present a commit message editor populated with
text *before* starting the commit. This fundamentally conflicts with
the idea that the text to populate it with depends on the commit being
made (which is how templates are defined to work at the moment). So:

  * if a template-generation hook doesn't actually depend on anything
    specific to an in-progress commit, then qbzr is missing out on using
    it purely due to API friction, which is a shame, and we could address
    this I think. Are there templates like this out there?
  * if qbzr would like that initial text to contain the template as if a
    full commit of files in the tree were about to happen, that can be
    fairly easily accomodated via the existing hook by starting the
    commit, capturing the message template for that commit, then aborting
    that commit. We don't yet have a clean way for a hook to abort the
    commit, but that can be fixed.
     * this has the downside of duplicating the effort to set up the
       commit, e.g. gathering changes, which is a shame.
     * although as an optimisation, qbzr could suspend rather than abort
       the commit, and if the user doesn't change the list of files etc
       to commit, then actually allow the original commit to finish (with
       the modified message)
     * the subprocess design of qbzr makes this a bit awkward to do, but
       I don't think it's particularly difficult. I'd be happy to talk
       about this in person at UDS.
     * in the longer term, I imagine we could provide an API that
       supported this more efficiently than “run commit twice”.
  * I think some concrete use cases about what message templates qbzr
    wants to see and use would help immensely. The discussions so far
    have been a bit bogged down in abstract issues, and I think some
    concrete examples of what qbzr wants to support would help, because
    it might spark some ideas about simpler solutions for those examples
    than rearchitecting large parts of bzr or qbzr. I'm thinking of
    concrete examples of text qbzr would like to show in various
    situations.

-Andrew.