emacs-devel
[Top][All Lists]
Advanced

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

Re: master 5022e27: ; Do not overwrite preexisting contents of unread-co


From: David Kastrup
Subject: Re: master 5022e27: ; Do not overwrite preexisting contents of unread-command-events
Date: Sat, 08 Aug 2015 17:04:31 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>>>> Surely this change deserved to create a ChangeLog entry, rather than
>>>> being marked with "; " to exclude that.
>>> A ChangeLog entry would run over several dozens of lines and take the
>>> better part of an hour to create since C-x v a does not work with Git.
>>> I figured that nobody would even notice anyway.
>
> I think what Glenn said, was that the entry should not have started
> with ";".  That would have generated a sub-optimal ChangeLog entry,
> but that's better than no ChangeLog entry.

Let me make very clear that I looked at CONTRIBUTE first and finally
went by

- Start with a single unindented summary line explaining the change;
  do not end this line with a period.  If that line starts with a
  semi-colon and a space "; ", the log message will be ignored when
  generating the ChangeLog file.  Use this for minor commits that do
  not need separate ChangeLog entries, such as changes in etc/NEWS.

since the only listed alternative was a full GNU-style ChangeLog commit
message.  Without looking at CONTRIBUTE, I would have written up a
commit message like I do on other projects, _not_ listing every filename
and function name (which are listed in the accompanying context diff
"git log -p" produces).  That would have been little work and would have
made every bit of information readily accessible that one would want.

I was not sure that the ChengeLog-entry free variant was really the best
choice.  That's one of the reason I posted the patch for comment on the
Emacs-devel list.

I'll prepare a ChangeLog entry like Eli described and commit it.
I really cannot imagine that it will be useful ever to anybody as the
collection of function names and affected files is a rather random
assortment (I could not name a single one in spite of creating the
patch).  So I skipped out on work I could not imagine anyone to want.
I was wrong on that but in my defense I did solicit for feedback.

-- 
David Kastrup



reply via email to

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