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