How to re-orgranize ChangeLog.unicode for merging

[Kenichi Handa]

I have a few questions about how to re-orgranize
ChangeLog.unicode for merging.

(1) As emacs-unicode-2 branch has very long history, the
changes have been made not only by me.  If the same function
has been modified by multiple persons, should we sumup
changes for each person?  If so, the result will be
confusing because we loose the time-line of changes.

DATE1 CHANGE1 by A
DATE2 CHANGE2 by B
DATE3 CHANGE3 by A
DATE4 CHANGE4 by B

will result in:

by A
  CHANGE1
  CHANGE3
by B
  CHANGE2
  CHANGE4

But, usually, it's important to know that CHANGE4 is done
after CHANGE3.

(2) The log files contain this kind of information.

2007-02-15  Kenichi Handa  <address@hidden>

        These changes are to compile a regexp into a pattern that can be
        used both for multibyte and unibyte targets.

        * Makefile.in (search.o): Depend on charset.h.
        ...
[...]
2006-06-06  Kenichi Handa  <address@hidden>

        These changes are for the new font handling codes.

        * character.c (multibyte_char_to_unibyte_safe): New function.
        ...

How to keep this kind of summary information when we sum up
changes.

(3) RMS wrote:

  > The most important part of the massaging is to get rid of duplicate
  > entries.  For instance suppose a function named foo is added and then
  > changed 10 times.  There will be 11 change log entries for it, but we
  > we only need to keep one: "New function".

Even for a new funciton, I want to know why some piece of
code is in the current shape.  I many times encountered such
a case that I don't remember why I wrote some code as the
current way.  In such a case, I read changelogs and get a
hint.  So, I don't want to loose the current information.
If you don't insist on having just one entry for changes of
a non-new function, please apply that also to a new
function.  For instance, I want to keep all of these
information.

        (insert_from_gap): Adjust intervals correctly.
        (insert_from_gap): Fix argument to offset_intervals.
        (insert_from_gap): Make it work even if PT != GTP.
        (insert_from_gap): Call record_insert.
        (insert_from_gap): New function.

Then, for instance, I can know (or recall) that the function
is intentionally coded to work in the PT != GTP case.

---
Kenichi Handa
address@hidden