Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Dmitry Gutov]

On 04/06/2015 01:20 PM, Artur Malabarba wrote:
> branch: master
> commit b6610d55470c7e835472a581977ab6fad537c8b6
> Author: Artur Malabarba <bruce.connor.am@gmail.com>
> Commit: Artur Malabarba <bruce.connor.am@gmail.com>
>
>      emacs-lisp/package.el: Refactor pre-execute prompt

Weekly reminder: commit messages should contain (almost) the same text 
as what's added to the ChangeLog files.

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Eli Zaretskii]

> Date: Mon, 06 Apr 2015 13:51:40 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 04/06/2015 01:20 PM, Artur Malabarba wrote:
> > branch: master
> > commit b6610d55470c7e835472a581977ab6fad537c8b6
> > Author: Artur Malabarba <bruce.connor.am@gmail.com>
> > Commit: Artur Malabarba <bruce.connor.am@gmail.com>
> >
> >      emacs-lisp/package.el: Refactor pre-execute prompt
> 
> Weekly reminder: commit messages should contain (almost) the same text 
> as what's added to the ChangeLog files.

I actually don't understand why those changes were pushed piecemeal,
and not as a single commit.  They sound like a single changeset to me.

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 208 bytes --]

> Weekly reminder: commit messages should contain (almost) the same text as
what's added to the ChangeLog files.

Sorry about that.
Hopefully, this reminder will no longer be necessary starting tomorrow. :-)

[-- Attachment #2: Type: text/html, Size: 278 bytes --]

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Artur Malabarba]

> I actually don't understand why those changes were pushed piecemeal,
> and not as a single commit.  They sound like a single changeset to me.

There are many ways to divide changes into changesets. Sorry if mine
was a little too detailed. The way I learned to do DVCS was to make
commits small enough to be human-readable, but large enough that each
one corresponds to a full working state (all tests passing, etc).

Each one of these commits makes a significant change to at least 2
functions, and I found them hard to read in a single commit so I split
into a few. (In retrospect, the "package-install" commit turned out a
bit trivial, and could be part of another one).

Do we have an objective definition of what a changeset should be?

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Eli Zaretskii]

> Date: Mon, 6 Apr 2015 15:01:22 +0100
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> > I actually don't understand why those changes were pushed piecemeal,
> > and not as a single commit.  They sound like a single changeset to me.
> 
> There are many ways to divide changes into changesets. Sorry if mine
> was a little too detailed. The way I learned to do DVCS was to make
> commits small enough to be human-readable, but large enough that each
> one corresponds to a full working state (all tests passing, etc).

What's below follows my personal preferences, so please don't take it
as a mandatory requirement of some sort, just food for thought.

> Each one of these commits makes a significant change to at least 2
> functions, and I found them hard to read in a single commit so I split
> into a few. (In retrospect, the "package-install" commit turned out a
> bit trivial, and could be part of another one).

What I would do in this situation is work on a branch, make
fine-grained commits there, and then merge them all onto master in a
single merge-commit.  Then, if someone follows first-parent, they'd
see a single commit with the feature, while still being able to
discern the separate commits you made during development.

IOW, I personally prefer not to see partial commits when I follow
first-parents.

> Do we have an objective definition of what a changeset should be?

No, it's a judgment call.  For me, an important question that helps
the decision is "will I ever want to revert that single changeset?"
YMMV, most probably.

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Artur Malabarba]

> What I would do in this situation is work on a branch, make
> fine-grained commits there, and then merge them all onto master in a
> single merge-commit.  Then, if someone follows first-parent, they'd
> see a single commit with the feature, while still being able to
> discern the separate commits you made during development.

Thanks, I like that idea.

> No, it's a judgment call.  For me, an important question that helps
> the decision is "will I ever want to revert that single changeset?"
> YMMV, most probably.

Ok. The question I usually ask myself is “Is it conceivable this
changeset might intruduce a bug?”
This way tools like git bisect become considerably more useful (not
that I've ever had to use it for Emacs specifically).

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Harald Hanche-Olsen]

Artur Malabarba wrote:
> This way tools like git bisect become considerably more useful (not
> that I've ever had to use it for Emacs specifically).

Speaking of which, I don't understand how git bisect can work properly 
with a history that is full of branching and remerging. The whole 
concept seems to require a linear history. What am I missing?

– Harald

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Artur Malabarba]

> Speaking of which, I don't understand how git bisect can work properly with
> a history that is full of branching and remerging. The whole concept seems
> to require a linear history. What am I missing?
>
> – Harald

git bisect searches the history of a single branch, and the history of
each branch is linear.

When you create other branches that doesn't affect the history of the
parent branch. And when you merge another branch onto the current one,
all it does is add a bunch of commits to it (which is linear).

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Harald Hanche-Olsen]

Artur Malabarba wrote:
> git bisect searches the history of a single branch, and the history of
> each branch is linear.
>
> When you create other branches that doesn't affect the history of the
> parent branch. And when you merge another branch onto the current one,
> all it does is add a bunch of commits to it (which is linear).

I don't understand. Say someone creates a branch foo from master. Then 
each branch has several commits, and foo is merged into master. How do 
you linearly order the commits that happened on the separate branches?

As far as I understand the bisection method, it relies on a linear order 
with this property: You are looking for a bug which was introduced at an 
unknown commit B, and you need to be assured that the bug will be absent 
in commit X if, and only if, X is before B in the linear order used. I 
don't see how you can define such a linear order in the above scenario. 
(We're assuming that the bug is present in X if and only if X is either 
equal to B or a descendant of B.)

– Harald

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Eli Zaretskii]

> Date: Mon, 06 Apr 2015 18:54:51 +0200
> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> I don't understand. Say someone creates a branch foo from master. Then 
> each branch has several commits, and foo is merged into master. How do 
> you linearly order the commits that happened on the separate branches?

AFAIU, in this case bisect will blame the merge-commit, and you can
then bisect further the merged branch, by starting bisect with the
second parent of the merge.

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Harald Hanche-Olsen]

Harald Hanche-Olsen wrote:

> I don't understand. Say someone creates a branch foo from master. Then
> each branch has several commits, and foo is merged into master. How do
> you linearly order the commits that happened on the separate branches?

Ah, but I am just being silly here. I got thrown by the name “bisect”. 
Of course, it doesn't always have to be bisection the way you do it in a 
linear order! Instead, assuming the bug was introduced when the branches 
were separate, the method needs to check the merge commit, and if the 
bug is present there, check the commit where the branches diverged, and 
if it is absent there, check the two branches separately.
If there is more branching, do it recursively. This is not rocket 
science. It's just the “bisect” name that is misleading.

Sorry about the noise.

– Harald

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Artur Malabarba]

>> git bisect searches the history of a single branch, and the history of
>> each branch is linear.
>>
>> When you create other branches that doesn't affect the history of the
>> parent branch. And when you merge another branch onto the current one,
>> all it does is add a bunch of commits to it (which is linear).
>
>
> I don't understand. Say someone creates a branch foo from master. Then each
> branch has several commits, and foo is merged into master. How do you
> linearly order the commits that happened on the separate branches?

Once foo is merged into master, all the commits made in foo are added
to master, and an additional merge commit is created.
As Eli mentioned, git bisect may point you to the merge commit, but it
depends on how nasty the merge was. It may also point you to one of
foo's commits (because they are now on master as well).

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]

On 04/06/2015 06:49 AM, Artur Malabarba wrote:
>
> > Weekly reminder: commit messages should contain (almost) the same 
> text as what's added to the ChangeLog files.
>
> Sorry about that.
> Hopefully, this reminder will no longer be necessary starting 
> tomorrow. :-)
>

I hope so too, but I'm afraid that some sort of reminder will still be 
needed, as not every project uses ChangeLog format for commit messages 
as our guidelines suggest, and many people aren't used to the suggested 
style.

This is not a new problem: many ChangeLog entries don't follow our 
guidelines and someone else tidies them up later, which is a pain for 
the "someone else".  If we can encourage more-standard commit messages, 
we can ease the maintenance burden.

Attached is a brief commentary on recently-added commit messages, which 
I've turned into ChangeLog format using the automated procedure that 
should be in place shortly, along with some commentary about possible 
improvements to these commit messages.

[-- Attachment #2: ChangeLog.txt --]
[-- Type: text/plain, Size: 13008 bytes --]

2015-04-06  Artur Malabarba  <bruce.connor.am@gmail.com>

	* emacs-lisp/package.el: Make the execute prompt less verbose.
[Omit "." at end of summary line.]
	(package-menu--list-to-prompt): New function.
	(package-menu--prompt-transaction-p): Use "Upgrade" to make the
	package-menu-execute prompt less verbose.

	* emacs-lisp/package.el: Fix lack of "new" packages.
[Omit "." at end of summary line.]
	(package-menu--new-package-list)
	(package-menu--old-archive-contents): No longer local.

2015-04-06  Eli Zaretskii  <eliz@gnu.org>

	src/w32proc.c: Fix typos in description of subprocess support.
[The previous line should have "* " at start.]

	Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs
[The previous line is not needed, as it is out of place in a ChangeLog
for 'master'.  Perhaps we should change the ChangeLog builder to omit
all commit messages of this form.]

2015-04-06  Koichi Arakawa  <arakawa@pp.iij4u.or.jp>

	Avoid segfaults on MS-Windows when invoking subprocesses  (Bug#20264)
[The suggested style is now to add "Fixes: bug#20264" as a separate line.]

	 src/w32proc.c (w32_executable_type): Look for the DLL name in the
	 correct section.  This avoids segfaults with some executables.
[Missing "*" at start of first line.  Also, no need to indent further.]

2015-04-06  Artur Malabarba  <bruce.connor.am@gmail.com>

	* NEWS: Document async package-menu.

	emacs-lisp/package.el (package-menu-execute): Add async support
	Most install/delete logic is now in
	`package-menu--perform-transaction', and this function is called
	asynchronously if `package-menu-async' is non-nil.

	emacs-lisp/package.el (package-install): Add ASYNC and CALLBACK

	emacs-lisp/package.el: Refactor pre-execute prompt

	emacs-lisp/package.el: Async support in download-transaction

[Each file name above should start with "* ".]

2015-04-05  Paul Eggert  <eggert@cs.ucla.edu>

	Spelling fix for 'hfy-optimizations'
	* htmlfontify.el (hfy-optimizations): Rename from hfy-optimisations,
	with an obsolete alias.  All uses changed.

	Fix typo in previous rtree change

	Use American spelling for 'normalize'
	* rtree.el (rtree-normalize-range): Rename from rtree-normalise-range.
	All uses changed.  Add an alias for obsolete usages.

2015-04-05  Fabián Ezequiel Gallina  <fgallina@gnu.org>

	Fix previous commit to prevent infloop

	python.el: Enhance docstring detection following PEP-257.
	* lisp/progmodes/python.el (python-docstring-at-p): Remove function.
	(python-info-assignment-statement-p): New function.
	(python-info-assignment-continuation-line-p): Use it.
	(python-info-docstring-p): New function.
	(python-font-lock-syntactic-face-function)
	(python-fill-string): Use it.
	* test/automated/python-tests.el (python-info-assignment-statement-p-1)
	(python-info-assignment-statement-p-2)
	(python-info-assignment-statement-p-3, python-info-docstring-p-1)
	(python-info-docstring-p-2, python-info-docstring-p-3)
	(python-info-docstring-p-4, python-info-docstring-p-5)
	(python-info-docstring-p-6): New tests.

2015-04-05  Eli Zaretskii  <eliz@gnu.org>

	Fix byte-compilation warning in lisp/ses.el
	 lisp/ses.el (ses-sym-rowcol): Move up, before the first use, to avoid
	 byte-compiler warnings.
[The file name should have "*" at the start of the line, and there's
no need to indent either line.]

2015-04-05  Alan Mackenzie  <acm@muc.de>

	Tidy up fix to debbugs#20240.
[Omit "." at end of summary line.]
[Should be "Fixes: bug#NNNN" line.]
	* jit-lock.el (jit-lock-after-change): Widen the buffer only
	whilst putting the 'fontified text properties.

2015-04-05  Eli Zaretskii  <eliz@gnu.org>

	Fix lisp/ChangeLog formatting.

2015-04-05  Alan Mackenzie  <acm@muc.de>

	Rationalize use of c[ad]+r, expunging cl-c[ad]\{3,4\}r.
[Omit "." at end of summary line.]
	Also expunge eudc-c[ad]+r.
	* subr.el (internal--compiler-macro-cXXr): "New" function, copied
	from cl--compiler-macro-cXXr.
	(caar, cadr, cdar, cddr): Change from defsubsts to defuns with
	the above compiler-macro.
	* net/eudc.el (eudc-cadr, eudc-cdar, eudc-caar, eudc-cdaar): Remove.
	* emacs-lisp/cl.el (Top level dolist doing defaliases): Remove
	caaar, etc., from list of new alias functions.
	* emacs-lisp/cl-lib.el (cl-caaar, etc): Rename to caaar, etc.
	(gen-cXXr--rawname, gen-cXXr-all-cl-aliases): New function/macro
	which generate obsolete cl- aliases for caaar, etc.  Invoke them.
	* desktop.el:
	* edmacro.el:
	* emacs-lisp/cl-macs.el:
	* frameset.el:
	* ibuffer.el:
	* mail/footnote.el:
	* net/dbus.el:
	* net/eudc-export.el:
	* net/eudc.el:
	* net/eudcb-ph.el:
	* net/rcirc.el:
	* net/secrets.el:
	* play/5x5.el:
	* play/decipher.el:
	* play/hanoi.el:
	* progmodes/hideif.el:
	* ses.el: Replace cl-caaar, eudc-cadr, etc. with caaar and cadr, etc.

2015-04-05  Richard Stallman  <rms@gnu.org>

	Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs
	Conflicts:
		lisp/ChangeLog

	       * mail/rmail.el (rmail-show-message-1): When displaying a mime message,        indicate start and finish in the echo area.
[The previous line should be two lines; neither should be indented.]
	       * mail/rmail.el (rmail-epa-decrypt): Disregard <pre> before armor.
	       Ignore more kinds of whitespace in mime headers.
	       Modify the decrypted mime part's mime type so it will be displayed
	       by default when visiting this message again.
	       * net/browse-url.el (browse-url-firefox-program): Prefer IceCat, doc.
	       (browse-url-firefox-arguments)
	       (browse-url-firefox-startup-arguments): Doc fix.
[The above lines should not be indented; that would fix their lengths.]

2015-04-05  Artur Malabarba  <bruce.connor.am@gmail.com>

	emacs-lisp/package.el: Add package-initialize to user-init-file.

	emacs-lisp/package.el: Prevent outdated downloads-in-progress.

2015-04-05  Michael Albinus  <michael.albinus@gmx.de>

	Remove entry from last sync with emacs-24, it wasn't applicable

2015-04-04  Pete Williamson  <petewil@chromium.org>

	Fix .emacs and .emacs.d/init file recursion problem for NaCl
	* files.el (file-truename): Add NaCl to the exception list ms-dos uses.

2015-04-04  Paul Eggert  <eggert@cs.ucla.edu>

	Merge from origin/emacs-24
	21d4bf6 * admin/make-tarball.txt: Copyedits.
	f3b70a7 ; ChangeLog fix
	07432a8 Revert "CC Mode: Stop Font Lock forcing fontification from BOL."
	Conflicts:
		lisp/ChangeLog

	Merge from origin/emacs-24
	The following commit was skipped:
	0ad5fe0 * etc/AUTHORS: Update the AUTHORS file

	Merge from origin/emacs-24
	dd3f567 Fix tramp-tests.el
	Conflicts:
		test/ChangeLog

	Merge from origin/emacs-24
	The following commit was skipped:
	1b70aa6 Fix bug#20233, do not merge with master

2015-04-04  Artur Malabarba  <bruce.connor.am@gmail.com>

	(package--with-work-buffer-async): Protect macro arguments.

	emacs-lisp/package.el: Don't overwrite downloads-in-progress.

2015-04-04  Michael Albinus  <michael.albinus@gmx.de>

	Quote directory name in tramp-flush-directory-property
	* net/tramp-cache.el (tramp-flush-directory-property): Quote directory
	name when used in regexp.

2015-04-04  Jan D  <jan.h.d@swipnet.se>

	Close a timing hole in selections.
[Omit "." at end of summary line.]
	Fixes: debbugs:16737
[Should be "Fixes: bug#NNNN"]
	* src/xselect.c (x_reply_selection_request)
	(receive_incremental_selection): Call set_property_change_object
	inside block_input.
	(wait_for_property_change): Move set property_change_reply(_object)
	outside of this function.
	(set_property_change_object): New function.

2015-04-04  Alan Mackenzie  <acm@muc.de>

	Fix debbugs#20240 part two (jit-lock error during `comment-dwim').
[Omit "." at end of summary line.]
[Should be a separate line with "Fixes: bug#NNNN".]
	jit-lock.el (jit-lock-after-change): Widen the buffer before
	putting 'fontified text properties.
[The file name should have "* " at the start of the line.]

2015-04-04  Ulrich Müller  <ulm@gentoo.org>

	configure.ac: Update comment.

2015-04-03  Paul Eggert  <eggert@cs.ucla.edu>

	Port 'configure' to clang 3.5
	* configure.ac: Add -Wno-unknown-attributes if clang; otherwise
	clang 3.5.0 (Fedora 21 x86-64) complains
	"/usr/include/glib-2.0/glib/gmem.h: ... warning: unknown attribute
	'__alloc_size__' ignored".  Use -Werror when checking for -nopie;
	otherwise clang warns about -nopie instead of failing, and then
	later it warns everytime the build uses -nopie.

2015-04-03  Michael Albinus  <michael.albinus@gmx.de>

	Fix Bug#20249
[Summary line could be clearer.]
	Fixes: debbugs:20249
[Should be "Fixes: bug#NNNN"]
	* net/tramp-cache.el (tramp-flush-file-property)
	(tramp-flush-directory-property): Use `directory-file-name' of the
	truename.

2015-04-03  Glenn Morris  <rgm@gnu.org>

	* admin/make-tarball.txt: Copyedits.

2015-04-03  Alan Mackenzie  <acm@muc.de>

	Revert "CC Mode: Stop Font Lock forcing fontification from BOL.  Bug#19669."
[Should be "Fixes: bug#NNNN"]
	This reverts commit d69e9f1c24f37f36af33b0468c5a4e100dbb09b6.

2015-04-03  Jan D  <jan.h.d@swipnet.se>

	Don't optimized away tool tip redraw, may lead to corrupted text.
[Omit "." at end of summary line.]
	* src/xterm.c (handle_one_xevent): Always redraw tool tips on
	MapNotify.  Update tool tip frame sizes on ConfigureNotify.

2015-04-03  Nicolas Richard  <theonewiththeevillook@yahoo.fr>

	pcmpl-ssh-known-hosts: Use `char-before' instead of `looking-back'.
[Omit "." at end of summary line.]
	Fixes: debbugs:17284
[Should be "Fixes: bug#NNNN"]
	* lisp/pcmpl-unix.el (pcmpl-ssh-known-hosts): Use `char-before' instead
	of `looking-back'.

2015-04-03  Ulrich Müller  <ulm@gentoo.org>

	configure.ac: Add -nopie to LD_SWITCH_SYSTEM_TEMACS.
[Omit "." at end of summary line.]
	* configure.ac (LD_SWITCH_SYSTEM_TEMACS): Add -nopie option if it
	is supported, in order to avoid segfaults in temacs.  (Bug#18784)
[Should be "Fixes: bug#NNNN"]

2015-04-02  Dmitry Gutov  <dgutov@yandex.ru>

	js-mode: Don't indent inside a multiline string literal
	* lisp/progmodes/js.el (js-indent-line): Do nothing when bol is inside
	a string (https://github.com/mooz/js2-mode/issues/227).

2015-04-02  Katsumi Yamaoka  <yamaoka@jpl.org>

	lisp/gnus/gnus-art.el (gnus-article-browse-html-parts): Make external links absolute and cid file names relative
[Line too long]

2015-04-02  Stefan Monnier  <monnier@iro.umontreal.ca>

[Missing summary line.]
	* lisp/abbrev.el (define-abbrev-table): Treat a non-string "docstring" as
	part of the "props" arguments rather than silently ignoring it.

	* lisp/emacs-lisp/lisp-mnt.el (lm-version): Don't burp in a non-file buffer.

2015-04-01  Nicolas Petton  <nicolas@petton.fr>

	* etc/AUTHORS: Update the AUTHORS file

2015-04-01  Alan Mackenzie  <acm@muc.de>

	Fix the CC Mode fixes from 2015-03-30.  Fixes debbugs#20240.
[Omit "." at end of summary line.]
[Should be "Fixes: bug#NNNN"]
	* progmodes/cc-mode.el (c-extend-after-change-region): Widen before
	applying text properties.
	* progmodes/cc-langs.el (c-before-font-lock-functions): Update an entry
	to a new function name.

2015-04-01  Paul Eggert  <eggert@cs.ucla.edu>

	* emacs-lisp/package.el: Spelling fixes and use active voice.

2015-04-01  Artur Malabarba  <bruce.connor.am@gmail.com>

	automated/package-test.el (package-test-update-archives): Fix test

2015-04-01  Michael Albinus  <michael.albinus@gmx.de>

	Fix tramp-tests.el
	* automated/tramp-tests.el (tramp-test06-directory-file-name):
	Fix docstring and last test.

2015-04-01  Artur Malabarba  <bruce.connor.am@gmail.com>

	* automated/package-test.el: Avoid async while testing.

	* emacs-lisp/package.el: Make package-menu asynchronous.
	(package-menu-async): New variable.  Controls whether
	`list-packages' is asynchronous.
	(list-packages): Now asynchronous by default.
	(package-menu--new-package-list): Always buffer-local.
	(package-menu--post-refresh)
	(package-menu--find-and-notify-upgrades)
	(package-menu--populate-new-package-list): New functions.

	* emacs-lisp/package.el: Implement asynchronous refreshing.
	(package--with-work-buffer-async)
	(package--check-signature-content)
	(package--update-downloads-in-progress): New functions.
	(package--check-signature, package--download-one-archive)
	(package--download-and-read-archives, package-refresh-contents):
	Optional arguments for async usage.
	(package--post-download-archives-hook): New variable. Hook run
	after every refresh.


Copyright (C) 2015 Free Software Foundation, Inc.

This file is part of GNU Emacs.

GNU Emacs is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

GNU Emacs is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

> I hope so too, but I'm afraid that some sort of reminder will still be
> needed, as not every project uses ChangeLog format for commit messages as
> our guidelines suggest, and many people aren't used to the suggested
style.
>
> This is not a new problem: many ChangeLog entries don't follow our
> guidelines and someone else tidies them up later, which is a pain for the
> "someone else". If we can encourage more-standard commit messages, we can
> ease the maintenance burden.
>
> Attached is a brief commentary on recently-added commit messages, which
I've
> turned into ChangeLog format using the automated procedure that should be
in
> place shortly, along with some commentary about possible improvements to
> these commit messages.
Thanks Paul, that's helpful.

Is there a reason why we need the * in the summary line? Can't these be
added when the changelog is generated?
The summary line is usually short on space.

[-- Attachment #2: Type: text/html, Size: 1089 bytes --]

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Stephen J. Turnbull]

Artur Malabarba writes:

 > Once foo is merged into master, all the commits made in foo are added
 > to master, and an additional merge commit is created.

That's a controversial interpretation.  Not wrong, but many people
like to think of "the branch" as being a linear history following
first parents.  AFAIK everybody agrees on the term "reachable from"
master to describe how commits from the source branch are "added to"
the target branch.