bug#20717: attribution of gitmerge.el merged entries in generated ChangeLog

bug#20717: attribution of gitmerge.el merged entries in generated ChangeLog

[Glenn Morris]

Package: emacs
Version: 25.0.50

After using M-x gitmerge (which seems v nice, BTW), 'make ChangeLog'
creates a file with contents:

2015-06-01  Glenn Morris  <rgm@...>

   Merge from origin/emacs-24
   8b5f2f4 * doc/emacs/emacs.texi: Update the ISBN of the Emacs manual.

The merged entries should be listed under the name of the original
author(s), not the name of the person who did the merge.

bug#20717: attribution of gitmerge.el merged entries in generated ChangeLog

[Glenn Morris]

Glenn Morris wrote:

> After using M-x gitmerge (which seems v nice, BTW), 'make ChangeLog'
> creates a file with contents:
>
> 2015-06-01  Glenn Morris  <rgm@...>
>
>    Merge from origin/emacs-24
>    8b5f2f4 * doc/emacs/emacs.texi: Update the ISBN of the Emacs manual.
>
> The merged entries should be listed under the name of the original
> author(s), not the name of the person who did the merge.

Oh, I see we actually get both. The above entry on the date of the
merge, and another entry (with the correct attribution) on the date the
change was originally made (which of course has zero relation to the
merge date) in the original branch. And changes that were skipped from
the merge are still included. What a confusing mess.

bug#20717: attribution of gitmerge.el merged entries in generated ChangeLog

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 05 Jun 2015 18:06:49 -0400
> 
> Glenn Morris wrote:
> 
> > After using M-x gitmerge (which seems v nice, BTW), 'make ChangeLog'
> > creates a file with contents:
> >
> > 2015-06-01  Glenn Morris  <rgm@...>
> >
> >    Merge from origin/emacs-24
> >    8b5f2f4 * doc/emacs/emacs.texi: Update the ISBN of the Emacs manual.
> >
> > The merged entries should be listed under the name of the original
> > author(s), not the name of the person who did the merge.
> 
> Oh, I see we actually get both. The above entry on the date of the
> merge, and another entry (with the correct attribution) on the date the
> change was originally made (which of course has zero relation to the
> merge date) in the original branch. And changes that were skipped from
> the merge are still included. What a confusing mess.

I'm guessing that you are using "git log" to show this.  That command
could produce confusing results if you don't pay attention to branches
and ancestry of each commit, because it shows a non-linear history in
a linear fashion.  That's unlike what "bzr log" did, where it would
show only mainline commits by default, and if invoked with -n0, would
show the commits on branches indented.

I suggest to use "git log --graph" instead, where you should see that
one of these commits was on a branch, and the one that's attributed to
you is the merge-commit.

For commits on "mainline", you can use "git log --first-parent" to
show only mainline commits, but this will not help you in the case in
point.

bug#20717: attribution of gitmerge.el merged entries in generated ChangeLog

[Glenn Morris]

Eli Zaretskii wrote:

> I'm guessing that you are using "git log" to show this. 

No, I'm using `make ChangeLog' like I said in the original message.
This produces a ChangeLog which is a confusing mess where merges are involved.

bug#20717: attribution of gitmerge.el merged entries in generated ChangeLog

[Glenn Morris]

Glenn Morris wrote:

> Eli Zaretskii wrote:
>
>> I'm guessing that you are using "git log" to show this. 
>
> No, I'm using `make ChangeLog' like I said in the original message.
> This produces a ChangeLog which is a confusing mess where merges are
> involved.

To expand:
1. The dates of merged entries are wrong by an arbitrary amount.
You can see the "cairo" entries in current ChangeLog.2 for an example of
this. IIUC, this isn't fixable without getting the reflog involved.
Ref: http://lists.gnu.org/archive/html/emacs-devel/2014-12/msg00102.html

2. Entries that were "skipped" when gitmerge.el'ing from emacs-24 to
master still appear in the generated ChangeLog. Check tomorrow's
automatically updated ChangeLog.2 for examples of that. Or type `make
ChangeLog' today. You'll see entries like

2015-04-11  Ulrich Mueller <ulm>

       Bump Emacs version to 24.5.50.

that were skipped when merging from emacs-24. It's especially confusing
because if merging isn't done very often (and recent history suggests it
won't be), these entries will be offset from the relevant "Merge from
origin/emacs-24" entry by a large distance. This isn't an issue now
because the emacs-24 branch is basically dead, but it will be for the
next release.

I would hope that this one is fixable, with some work on admin/gitmerge.el
and/or build-aux/gitlog-to-changelog.

But I get the impression that a readable ChangeLog isn't much of a
priority for Emacs anymore. Maybe no-one will miss it.

bug#20717: attribution of gitmerge.el merged entries in generated ChangeLog

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 20717@debbugs.gnu.org
> Date: Sat, 06 Jun 2015 14:48:55 -0400
> 
> 1. The dates of merged entries are wrong by an arbitrary amount.
> You can see the "cairo" entries in current ChangeLog.2 for an example of
> this. IIUC, this isn't fixable without getting the reflog involved.
> Ref: http://lists.gnu.org/archive/html/emacs-devel/2014-12/msg00102.html
> 
> 2. Entries that were "skipped" when gitmerge.el'ing from emacs-24 to
> master still appear in the generated ChangeLog. Check tomorrow's
> automatically updated ChangeLog.2 for examples of that. Or type `make
> ChangeLog' today. You'll see entries like
> 
> 2015-04-11  Ulrich Mueller <ulm>
> 
>        Bump Emacs version to 24.5.50.
> 
> that were skipped when merging from emacs-24. It's especially confusing
> because if merging isn't done very often (and recent history suggests it
> won't be), these entries will be offset from the relevant "Merge from
> origin/emacs-24" entry by a large distance. This isn't an issue now
> because the emacs-24 branch is basically dead, but it will be for the
> next release.

Do logs of changes made on feature branches also appear like that, and
are also misplaced?  E.g., what do you get there of the commits on the
large-fonts branch I merged today?  They shouldn't appear at all, I
think.

> I would hope that this one is fixable, with some work on admin/gitmerge.el
> and/or build-aux/gitlog-to-changelog.

I hope so too.

> But I get the impression that a readable ChangeLog isn't much of a
> priority for Emacs anymore. Maybe no-one will miss it.

I will.

bug#20717: attribution of gitmerge.el merged entries in generated ChangeLog

[Glenn Morris]

Eli Zaretskii wrote:

> Do logs of changes made on feature branches also appear like that, and
> are also misplaced?  E.g., what do you get there of the commits on the
> large-fonts branch I merged today?

See
http://lists.gnu.org/archive/html/emacs-diffs/2015-06/msg00090.html

The word "merge" isn't even mentioned in gitlog-to-changelog, and it's 7
years old, so I assume no-one cares about such things. Frankly, it's not
much more than a dump of "git log" with some formatting tweaks to make
it look more like a ChangeLog.

bug#20717: attribution of gitmerge.el merged entries in generated ChangeLog

[Glenn Morris]

I've hopefully fixed the main issue, which is keeping gitmerge.el
"skipped" entries out of the ChangeLog. It might be possible to correct
the date of gitmerge'd entries, by tracking the date of the merge commit
and the hashes it mentions, and using that date for all those hashes
when they are found. By this won't work for normal merges, so it doesn't
really seem worth bothering with.

bug#20717: attribution of gitmerge.el merged entries in generated ChangeLog

[Glenn Morris]

There's obviously no interest in improving this, closing as wontfix.

bug#20717: attribution of gitmerge.el merged entries in generated ChangeLog

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 20717@debbugs.gnu.org
> Date: Wed, 10 Jun 2015 21:28:08 -0400
> 
> Eli Zaretskii wrote:
> 
> > Do logs of changes made on feature branches also appear like that, and
> > are also misplaced?  E.g., what do you get there of the commits on the
> > large-fonts branch I merged today?
> 
> See
> http://lists.gnu.org/archive/html/emacs-diffs/2015-06/msg00090.html
> 
> The word "merge" isn't even mentioned in gitlog-to-changelog, and it's 7
> years old, so I assume no-one cares about such things. Frankly, it's not
> much more than a dump of "git log" with some formatting tweaks to make
> it look more like a ChangeLog.

So should we manually correct the most glaring problems of the result
of this?  For example, the logs for commits I made on that branch
should be deleted, as there's a summary log for the merge-commit later
on that covers them all.

Perhaps we should recommend that people use the ";" trick in the log
messages they make on branches they intend to merge onto master later?

bug#20717: attribution of gitmerge.el merged entries in generated ChangeLog

[Stefan Monnier]

> For commits on "mainline", you can use "git log --first-parent" to
> show only mainline commits, but this will not help you in the case in
> point.

Not only that: it will not always show you what you wanted to see, since
it's much too easy to make a commit where the first parent is not the
previous revision on the trunk but the previous revision in your own
local branch instead (and much too hard to avoid this situation).


        Stefan