ChangeLog dates

ChangeLog dates

[Ulrich Mueller]

When merging commits or applying a patch, should the date in the
ChangeLog be left alone, or updated to the current date? In other
words, should the ChangeLog date be equal to git's AuthorDate (in
which case dates can be out of sequence) or CommitDate?

Ulrich

Re: ChangeLog dates

[Eli Zaretskii]

> Date: Thu, 27 Nov 2014 08:34:00 +0100
> From: Ulrich Mueller <ulm@gentoo.org>
> 
> When merging commits or applying a patch, should the date in the
> ChangeLog be left alone, or updated to the current date? In other
> words, should the ChangeLog date be equal to git's AuthorDate (in
> which case dates can be out of sequence) or CommitDate?

Until now we did the latter, i.e. updated the entry's date to the date
of the merge.  I don't know what's TRT when ChangeLog's will be
generated.

Re: ChangeLog dates

[Ted Zlatanov]

On Thu, 27 Nov 2014 18:12:13 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> Date: Thu, 27 Nov 2014 08:34:00 +0100
>> From: Ulrich Mueller <ulm@gentoo.org>
>> 
>> When merging commits or applying a patch, should the date in the
>> ChangeLog be left alone, or updated to the current date? In other
>> words, should the ChangeLog date be equal to git's AuthorDate (in
>> which case dates can be out of sequence) or CommitDate?

EZ> Until now we did the latter, i.e. updated the entry's date to the date
EZ> of the merge.  I don't know what's TRT when ChangeLog's will be
EZ> generated.

It's going to have to be the original date, because AFAIK it's part of
the commit hash.

Ted

Re: ChangeLog dates

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Thu, 27 Nov 2014 19:36:02 -0500
> 
> On Thu, 27 Nov 2014 18:12:13 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 
> 
> >> Date: Thu, 27 Nov 2014 08:34:00 +0100
> >> From: Ulrich Mueller <ulm@gentoo.org>
> >> 
> >> When merging commits or applying a patch, should the date in the
> >> ChangeLog be left alone, or updated to the current date? In other
> >> words, should the ChangeLog date be equal to git's AuthorDate (in
> >> which case dates can be out of sequence) or CommitDate?
> 
> EZ> Until now we did the latter, i.e. updated the entry's date to the date
> EZ> of the merge.  I don't know what's TRT when ChangeLog's will be
> EZ> generated.
> 
> It's going to have to be the original date, because AFAIK it's part of
> the commit hash.

Of course; even I know that.  But the script that generates ChangeLog
from the commit log could modify the dates, if we decide that to be
TRT.

Re: ChangeLog dates

[Ted Zlatanov]

(switching to the "ChangeLog dates" thread because it's more relevant)

On Fri, 28 Nov 2014 09:22:21 +0100 Andreas Schwab <schwab@linux-m68k.org> wrote: 

AS> Ted Zlatanov <tzz@lifelogs.com> writes:
TZ> I used the recommended gnulib driver:
>> 
TZ> [merge "merge-changelog"]
TZ> name = GNU-style ChangeLog merge driver
TZ> driver = /usr/local/bin/git-merge-changelog %O %A %B
>> 
>> I'm not sure if this means that `git-merge-changelog' doesn't work the
>> way the Emacs maintainers want, or that I used it incorrectly. Hints
>> welcome.

AS> You need to add this to .git/info/attributes:

AS> ChangeLog*	merge=merge-changelog

I already have it, sorry if that was unclear.  The merge driver is used,
my question was whether it does the right thing because of Glenn's
note about setting the date on merges, and in the end it may not matter
because...

On Fri, 28 Nov 2014 10:31:11 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Thu, 27 Nov 2014 19:33:50 -0500
>> 
TZ> [merge "merge-changelog"]
TZ> name = GNU-style ChangeLog merge driver
TZ> driver = /usr/local/bin/git-merge-changelog %O %A %B
>> 
>> I'm not sure if this means that `git-merge-changelog' doesn't work the
>> way the Emacs maintainers want, or that I used it incorrectly. Hints
>> welcome. Most importantly, I need to know if I leave this in my
>> gitconfig but try to use gitmerge.el, the result will be bad from the
>> maintainers' perspective.

EZ> I think you should keep that entry, but you need to examine the
EZ> results in ChangeLog anyway.  git-merge-changelog does try to be smart
EZ> about where to put merged ChangeLog entries, but it cannot always do a
EZ> perfect job.  AFAICS, gitmerge.el doesn't fix that (maybe it should
EZ> try), so manual labor is still required.

When we move to auto-generated ChangeLogs it will be irrelevant, so I
hope that's soon.

On Fri, 28 Nov 2014 10:33:41 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> Until now we did the latter, i.e. updated the entry's date to the date
EZ> of the merge.  I don't know what's TRT when ChangeLog's will be
EZ> generated.
>> 
>> It's going to have to be the original date, because AFAIK it's part of
>> the commit hash.

EZ> Of course; even I know that.

I didn't before I checked :)

EZ> But the script that generates ChangeLog from the commit log could
EZ> modify the dates, if we decide that to be TRT.

It will be painful and I think faking the date was an artifact of the
static ChangeLog system rather than actually needed. It would probably
be better to preserve the original commit date in the auto-generated
ChangeLog but add a note that the commit was merged/backported to branch
X on date Y.

Ted

Re: ChangeLog dates

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Fri, 28 Nov 2014 06:02:46 -0500
> 
> On Fri, 28 Nov 2014 10:33:41 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 
> 
> EZ> Until now we did the latter, i.e. updated the entry's date to the date
> EZ> of the merge.  I don't know what's TRT when ChangeLog's will be
> EZ> generated.
> >> 
> >> It's going to have to be the original date, because AFAIK it's part of
> >> the commit hash.
> 
> EZ> Of course; even I know that.
> 
> I didn't before I checked :)
> 
> EZ> But the script that generates ChangeLog from the commit log could
> EZ> modify the dates, if we decide that to be TRT.
> 
> It will be painful and I think faking the date was an artifact of the
> static ChangeLog system rather than actually needed. It would probably
> be better to preserve the original commit date in the auto-generated
> ChangeLog but add a note that the commit was merged/backported to branch
> X on date Y.

Seen from the master's POV, keeping the dates from the original
(branch) commits would be rewriting history, because the actual date
the commits appeared on master are different.

Re: ChangeLog dates

[Ted Zlatanov]

On Fri, 28 Nov 2014 13:06:54 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> It will be painful and I think faking the date was an artifact of the
>> static ChangeLog system rather than actually needed. It would probably
>> be better to preserve the original commit date in the auto-generated
>> ChangeLog but add a note that the commit was merged/backported to branch
>> X on date Y.

EZ> Seen from the master's POV, keeping the dates from the original
EZ> (branch) commits would be rewriting history, because the actual date
EZ> the commits appeared on master are different.

But the commit's date is "baked" into it by Git. So there's no "master"
POV for commit dates, only for when the commits are accessible via
"master" (and both dates are relevant, hence I suggested adding a note).

Ted

Re: ChangeLog dates

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Fri, 28 Nov 2014 08:57:41 -0500
> 
> EZ> Seen from the master's POV, keeping the dates from the original
> EZ> (branch) commits would be rewriting history, because the actual date
> EZ> the commits appeared on master are different.
> 
> But the commit's date is "baked" into it by Git. So there's no "master"
> POV for commit dates, only for when the commits are accessible via
> "master" (and both dates are relevant, hence I suggested adding a note).

I'm not talking about Git's history, or accessing history through Git.
I'm talking about ChangeLog files looked at by people who have only
the release tarball (which is why we produce ChangeLog files).  They
don't have Git, they have just the ChangeLog files, and those
ChangeLog files should IMO reflect the ordered sequence of commits to
the branch from which the tarball was created.

Re: ChangeLog dates

[Ted Zlatanov]

On Fri, 28 Nov 2014 16:06:11 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Fri, 28 Nov 2014 08:57:41 -0500
>> 
EZ> Seen from the master's POV, keeping the dates from the original
EZ> (branch) commits would be rewriting history, because the actual date
EZ> the commits appeared on master are different.
>> 
>> But the commit's date is "baked" into it by Git. So there's no "master"
>> POV for commit dates, only for when the commits are accessible via
>> "master" (and both dates are relevant, hence I suggested adding a note).

EZ> I'm not talking about Git's history, or accessing history through Git.
EZ> I'm talking about ChangeLog files looked at by people who have only
EZ> the release tarball (which is why we produce ChangeLog files).  They
EZ> don't have Git, they have just the ChangeLog files, and those
EZ> ChangeLog files should IMO reflect the ordered sequence of commits to
EZ> the branch from which the tarball was created.

I understand. I personally would be OK with either the original dates
with a side note, or the adjusted dates in such a packaged ChangeLog.

Thanks for explaining
Ted

Re: ChangeLog dates

[Glenn Morris]

Eli Zaretskii wrote:

> I'm talking about ChangeLog files looked at by people who have only
> the release tarball (which is why we produce ChangeLog files).  They
> don't have Git, they have just the ChangeLog files, and those
> ChangeLog files should IMO reflect the ordered sequence of commits to
> the branch from which the tarball was created.

I agree, and AFAICS, this is the only interpretation that makes any sense.
So the ChangeLog date of merged entries simply has to be adjusted to the
merge date.

This is how we've always done it, and there's no reason it should change
because the VCS changed, or if ChangeLog entries were not hand-written.