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 <address@hidden> wrote: 

AS> Ted Zlatanov <address@hidden> 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 <address@hidden> wrote: 

>> From: Ted Zlatanov <address@hidden>
>> 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 <address@hidden> 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