[RFC] Changing the generate_commit_message_template and commit_message_template hook APIs

[Robert Collins]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> 2009/9/14 Robert Collins <robertc at robertcollins.net>:
>> 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.

I think it *is* unreasonable for a general bzr UI to do this. I think
its reasonable for scripts etc that are written for specific purposes to
  use such a dry run approach.

> 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.

So this is' call back cross process', written another way :). I think
thats a sensible approach. I'm not sure that I'd use a named pipe to do
it rather than just chattering on stdin/stdout though :)

- -Rob
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqtwKsACgkQ42zgmrPGrq4CbgCgmkez/5HXEYQnWw+Z8fVN+g3m
S+AAnifzp8wERSsaTmOR9wnSfDg6XKMN
=3tA6
-----END PGP SIGNATURE-----