emacs-devel
[Top][All Lists]
Advanced

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

Re: VC commit missing ChangeLog message


From: Ted Zlatanov
Subject: Re: VC commit missing ChangeLog message
Date: Wed, 12 Nov 2008 15:42:30 -0600
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux)

On Wed, 12 Nov 2008 11:56:42 -0800 (PST) Dan Nicolaescu <address@hidden> wrote: 

DN> Ted Zlatanov <address@hidden> writes:
>> On Tue, 11 Nov 2008 17:11:06 -0800 (PST) Dan Nicolaescu <address@hidden> 
>> wrote: 
>> 
DN> If you are interested in improving this area, please also look at one of
DN> the TODO items in vc.el:
>> 
DN> ;; - When vc-next-action calls vc-checkin it could pre-fill the
DN> ;;   *VC-log* buffer with some obvious items: the list of files that
DN> ;;   were added, the list of files that were removed.  If the diff is
DN> ;;   available, maybe it could even call something like
DN> ;;   `diff-add-change-log-entries-other-window' to create a detailed
DN> ;;   skeleton for the log...
DN> ;;
>> 
>> I think that should be up to the user, to be done in the hook.  

DN> Sure, but it would be nice to provide a way to do it by default.

I think we agree that something is good, but it will be hard to agree on
the particulars of what to put in the buffer.  So maybe the answer is a
format-like string (falling back to a function call) that the user can
customize?

>> The information, diff and files added/removed/affected, exists
>> outside the commit message so putting it inside the message
>> duplicates the information.

DN> It exists, but it means you have to look in two places for it, it is
DN> customary to put such information in the logs.

Sorry, I don't see what you mean.  Putting it in the logs would ensure
you have two places to look, and when it's inaccurate it would be an
even worse situation.

DN> Also you only addressed one part of that TODO entry, the whole point is
DN> to make it easier to write log entries, and provide as much as possible
DN> by default.

The two goals diverge significantly once the threshold of "enough"
information is passed, and unfortunately that is a different point for
every user.

Specifically regarding the detailed skeleton, I think we're getting to
the format string/function concept I mentioned above.  I don't think
Emacs has a default way to do this, but skeleton.el should work.

Ted





reply via email to

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