Re: merging the unicode-2 branch (was: Re: Selection-set editing without VC-dired)

[Dan Nicolaescu]

Richard Stallman <address@hidden> writes:

  >       > Recent trends in VCS make the ChangeLog file more important.  The
  >       > reason I dropped my opposition to multi-file commits is that I
  >       > realized that the info I used to get by looking at a CVS log, I 
could get
  >       > from the ChangeLog file instead with a suitable selective visibility
  >       > mode.
  > 
  >     Can we then proceed with the unicode-2 branch merging then?
  > 
  > Sorry, I don't follow.  I think there is a misunderstanding here.
  > 
  >      Splitting
  >     the ChangeLog per file was what was blocking the merge.
  > 
  > I think that is the misunderstanding.  What I asked for was not
  > to "split" the ChangeLog file.  It was to simplify it,
  > getting rid of unnecessary duplicate entries.  For instance,
  > if we have
  > 
  >     (foobar): Change xyz.
  > 
  > and on a previous date
  > 
  >         (foobar): New function.
  > 
  > then we only need the latter.  If foobar is a new function, being
  > installed now, then we only need the "new function" entry.

Well, Handa-san didn't sound like he thought this would be a good
idea. Here is what he replied to you:

   (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.


And I also stated that given the experience with the work I've done for
doing such ChangeLog rewriting for the multi-tty merge the amount of
effort involved in doing this type of rewrite is non-trivial, it can be
at least a full day of work.  I have yet to see any benefit from all
that effort.