[RFC] Changing the generate_commit_message_template and commit_message_template hook APIs

[Martin Pool]

2009/9/14 Robert Collins <robertc at robertcollins.net>:
> On Sat, 2009-09-12 at 03:09 +0200, Gary van der Merwe wrote:
>> On Sat, Sep 12, 2009 at 12:53 AM, Robert Collins
>> <robertc at robertcollins.net> wrote:
>> > Why not just invoke tree.commit directly in qbzr?
>> >
>> > I don't see that a 'more clear' definition will help, if the template
>> > code wants to derive data about the commit that /is happening/, unless
>> > you are doing a commit, it will break.
>>
>> Well, that's the difference. I want the template before we do the
>> commit, when the dialogue gets opened.
>
> This is intrinsically incompatible with templates that want to (e.g.)
> show the files being committed.
>
> Consider:
>  - a plugin that automanages extra metadata (e.g. etckeeper). This
> plugin will cause files that are not supplied to the commit command line
> to be altered. (because its tracking additional permission bits)
>  - the template code that shows 'these files are being modified by the
> commit'
>
> Without running the whole commit twice, I don't see how to reconcile
> these two things :- and more complex example won't work even if you do
> run it twice.

Those are good cases to keep in mind, but I don't think it's
inherently unreasonable to say "do a dry-run commit and give me the
template", then later "actually commit, using this message."
Obviously there is some risk of the tree changing in the interim but I
can imagine people liking to use it from shell scripts or emacs or
other things.  It is a bit inefficient too.

Another (maybe weird) approach is to have the in-process commit editor
be: write the template to a tmp file, then connect to this named pipe
and read the message back from there.  That gives you a handoff to an
asynchronous process: it gets the template, does its thing, and when
the user presses ok opens that pipe and writes.  This will vary a bit
between unix and Windows but in principle (heh) it should work
everywhere.

> John says you're trying to solve a UI responsiveness issue? Is that so -
> what's the issue, I'd like to help you solve it.

-- 
Martin <http://launchpad.net/~mbp/>