Re: Commit netiquette.

[Alfred M. Szmidt]

   >> This seems more of a short comming in `bzr log --short' than in the
   >> way one writes commit messages.

   Not really: it's the whole idea behing "bzr log --short".

bzr log could create a short output in some other fashion, one line is
always often to short to explain a change anyway so this option does
not do much good.

   Could someone update log-edit-mode's font-lock patterns so that the
   first line is highlighted specially (at least in the Bzr and Arch
   cases)?

   I think log-edit-mode should even go further in this direction.
   The buffer should be created as

     ----------------
     Author: 
     Summary: 

     blablabla
     ----------------

   where <blablabla> is the text taken from the ChangeLog.  Then for
   backends which support the notion of summary-line, C-c C-c could
   just signal an error if the Summary line is still blank.

That seems overly forceful, emacs is not just by emacs developers, it
is used by an immense number of people.  There have been many changes
done recently that have not been thought through, nor discussed with
those who use emacs.  Please stop making such rash decisions; remeber
such changes not only affect you by anyone who uses emacs.

   After that, empty header entries will get removed and the text is
   passed as-is to the backend who is then free to pass it as-is to
   the underlying VCS or to extract the various fields and do whatever
   it feels like with them.

This will not help those who use C-c C-a in vc-mode.

A sensible way of attacking the problem would be to have a frob,
log-edit-message-style, this could be set using .dir-locals.el, per
file, or in .emacs.  It would affect how C-c C-a behaves, if it
inserts a ChangeLog entry the standard way, or if it also adds an
header.