[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