[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Commit netiquette.

From: Alfred M. Szmidt
Subject: Re: Commit netiquette.
Date: Fri, 19 Feb 2010 03:17:48 -0500

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

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



   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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]