Comment 5 for bug 788216

Revision history for this message
Alexander Belchenko (bialix) wrote : Re: [Bug 788216] Re: qbzr does not use commit message hooks

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.