ChangeLog entries

ChangeLog entries

[Eli Zaretskii]

Currently, ChangeLog.2 has entries like this:

  commit 45987b34535e5ae97fa14535630e283f34af94dd
  Merge: c208eef feadec3
  Author: Nicolas Petton <nicolas@petton.fr>
  Date:   Sat Aug 8 21:54:45 2015 +0200

      Merge remote-tracking branch 'origin/fix/subsequence-error-with-negative-seq

  commit feadec307da148af70cf87013c99771ca4db91e4
  Author: Phillip Lord <phillip.lord@newcastle.ac.uk>
  Date:   Fri Aug 7 22:12:59 2015 +0100

      Improve error signalling for seq-subseq.

      The existing behaviour for seq-subseq is to error when indexes are too
      large, but to silently ignore numbers which are too negative for lists.
      String and vector handling errors in both cases. This has been
      regularlised.

      Error signalling behaviour has been explicitly added to the docstring of
      seq-subseq, and also to cl-subseq which largely defers to
      seq-subseq (and is therefore also impacted by this change).

      Tests have been added for these exceptional cases, as well as one non
      exceptional base case.

I thought log entries from branches weren't supposed to end up in
ChangeLog, but if they are, I think we should delete these.

Re: ChangeLog entries

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

> Currently, ChangeLog.2 has entries like this:
>
>   commit 45987b34535e5ae97fa14535630e283f34af94dd
>   Merge: c208eef feadec3
>   Author: Nicolas Petton <nicolas@petton.fr>
>   Date:   Sat Aug 8 21:54:45 2015 +0200
>
>       Merge remote-tracking branch 'origin/fix/subsequence-error-with-negative-seq
>
>   commit feadec307da148af70cf87013c99771ca4db91e4
>   Author: Phillip Lord <phillip.lord@newcastle.ac.uk>
>   Date:   Fri Aug 7 22:12:59 2015 +0100
>
>       Improve error signalling for seq-subseq.
>
>       The existing behaviour for seq-subseq is to error when indexes are too
>       large, but to silently ignore numbers which are too negative for lists.
>       String and vector handling errors in both cases. This has been
>       regularlised.
>
>       Error signalling behaviour has been explicitly added to the docstring of
>       seq-subseq, and also to cl-subseq which largely defers to
>       seq-subseq (and is therefore also impacted by this change).
>
>       Tests have been added for these exceptional cases, as well as one non
>       exceptional base case.
>
> I thought log entries from branches weren't supposed to end up in
> ChangeLog, but if they are, I think we should delete these.


They are both changes to trunk. feadec was a change *originally* made on
a branch, 45987 is a merge commit pulling feadec onto trunk also. I
wanted Nicolas to okay by change given that it was his code.

Personally, I would have rebased, but a rebase vs merge discussion is
unlikely to add anything substantial to the world.

I'd rather feadec wasn't deleted. It's my first ChangeLog entry and I'm
really rather proud of it, pathetic as that might sound.

Phil

Re: ChangeLog entries

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: <emacs-devel@gnu.org>
> Date: Sun, 09 Aug 2015 16:46:20 +0100
> 
> They are both changes to trunk. feadec was a change *originally* made on
> a branch, 45987 is a merge commit pulling feadec onto trunk also. I
> wanted Nicolas to okay by change given that it was his code.

Then please in the future use the format we follow, which is identical
to ChangeLog entries: a function name in parentheses followed by the
description of what changes were made in that function.

> I'd rather feadec wasn't deleted. It's my first ChangeLog entry and I'm
> really rather proud of it, pathetic as that might sound.

I'm only talking about the form, not about the contents.  I suggest to
edit ChangeLog.2 to make this entry into its correct form, and commit
the change.

TIA

Re: ChangeLog entries

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: <emacs-devel@gnu.org>
>> Date: Sun, 09 Aug 2015 16:46:20 +0100
>> 
>> They are both changes to trunk. feadec was a change *originally* made on
>> a branch, 45987 is a merge commit pulling feadec onto trunk also. I
>> wanted Nicolas to okay by change given that it was his code.
>
> Then please in the future use the format we follow, which is identical
> to ChangeLog entries: a function name in parentheses followed by the
> description of what changes were made in that function.

Ah, okay, will do that in future.


>
>> I'd rather feadec wasn't deleted. It's my first ChangeLog entry and I'm
>> really rather proud of it, pathetic as that might sound.
>
> I'm only talking about the form, not about the contents.  I suggest to
> edit ChangeLog.2 to make this entry into its correct form, and commit
> the change.

Is the ChangeLog not autogenerated from the commit message? This is what
I had assumed. I can change the ChangeLog.2 without changing the commit
message?

Phil

Re: ChangeLog entries

[Artur Malabarba]

> Is the ChangeLog not autogenerated from the commit message? This is what
> I had assumed.

Yes, but only periodically, and once a given entry has been generated
it's not going to be generated again.

> I can change the ChangeLog.2 without changing the commit
> message?

Yes. Any changes you make to ChangeLog.2 will be permanent. When you
commit these changes, start the commit message with a semicolon so
that message itself doesn't generate an entry.

Re: ChangeLog entries

[Phillip Lord]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

>> Is the ChangeLog not autogenerated from the commit message? This is what
>> I had assumed.
>
> Yes, but only periodically, and once a given entry has been generated
> it's not going to be generated again.
>
>> I can change the ChangeLog.2 without changing the commit
>> message?
>
> Yes. Any changes you make to ChangeLog.2 will be permanent. When you
> commit these changes, start the commit message with a semicolon so
> that message itself doesn't generate an entry.


Thanks for the advice. I will update.

Phil

Re: ChangeLog entries

[Nicolas Petton]

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

Phillip Lord <phillip.lord@russet.org.uk> writes:

> Personally, I would have rebased, but a rebase vs merge discussion is
> unlikely to add anything substantial to the world.

I also usually rebase, I probably should have done it here too.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: ChangeLog entries

[Eli Zaretskii]

> From: Nicolas Petton <nicolas@petton.fr>
> Cc: emacs-devel@gnu.org
> Date: Mon, 10 Aug 2015 15:02:59 +0200
> 
> > Personally, I would have rebased, but a rebase vs merge discussion is
> > unlikely to add anything substantial to the world.
> 
> I also usually rebase, I probably should have done it here too.

You can do that if you want, assuming your branch is a simple one-off
feature branch, and you never merged from master onto it.  Otherwise,
you really need to know what you are doing when rebasing, or else you
will risk bringing the same changes more than once.

For this reason, we recommend that people who are not that fluent in
Git _do_ merge, and not rebase.  Since Emacs generally uses a
merge-based workflow between its official branches, merging (including
implicit merges done by "git pull") fits better than rebasing.

Re: ChangeLog entries

[Paul Eggert]

Merge-vs-rebase is a common point of disagreement among Git users. 
Although I typically rebase, sometimes merging is better.  My impression 
is that you really need to know what you're doing, regardless of whether 
you're merging or rebasing.

Re: ChangeLog entries

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Nicolas Petton <nicolas@petton.fr>
>> Cc: emacs-devel@gnu.org
>> Date: Mon, 10 Aug 2015 15:02:59 +0200
>> 
>> > Personally, I would have rebased, but a rebase vs merge discussion is
>> > unlikely to add anything substantial to the world.
>> 
>> I also usually rebase, I probably should have done it here too.
>
> You can do that if you want, assuming your branch is a simple one-off
> feature branch, and you never merged from master onto it.  Otherwise,
> you really need to know what you are doing when rebasing, or else you
> will risk bringing the same changes more than once.
>
> For this reason, we recommend that people who are not that fluent in
> Git _do_ merge, and not rebase.  Since Emacs generally uses a
> merge-based workflow between its official branches, merging (including
> implicit merges done by "git pull") fits better than rebasing.

I publicly apologise to everyone for attempting to make a joke about
rebase vs merge. I realise now that some issues are just fit topics for
humour, and that my joke was not funny anyway.

Phil

Re: ChangeLog entries

[Paul Eggert]

Eli Zaretskii wrote:
> I thought log entries from branches weren't supposed to end up in
> ChangeLog, but if they are, I think we should delete these.

If their commit logs all look like "Merge remote-tracking branch '.*'" we can 
easily automate that by adding that pattern to build-aux/gitlog-to-emacslog.  I 
did that just now.

Re: ChangeLog entries

[Eli Zaretskii]

> Date: Sun, 09 Aug 2015 09:05:33 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> Eli Zaretskii wrote:
> > I thought log entries from branches weren't supposed to end up in
> > ChangeLog, but if they are, I think we should delete these.
> 
> If their commit logs all look like "Merge remote-tracking branch '.*'" we can 
> easily automate that by adding that pattern to build-aux/gitlog-to-emacslog.  I 
> did that just now.

Thanks.