[qbzr] qcommit: support for templates/drafts of commit message?

Andrew Bennetts andrew.bennetts at canonical.com
Fri Apr 30 04:19:22 BST 2010


Gary van der Merwe wrote:
> On Thu, Apr 29, 2010 at 5:00 PM, Alexander Belchenko <bialix at ukr.net> wrote:
> > OK, I've re-read that old discussion and it seems I'm kicking the dead
> > horse. Therefore any attempts to change the signature of the hook is
> > useless.
> 
> Good thing to discuss at UDS.

I agree.  Meanwhile, some more thoughts...

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.




More information about the bazaar mailing list