Re: Status update - version 5.2.2, cvs->git conversion, plans

[Hans-Bernhard B. <HBB...@t-...>]

Am 16.11.2017 um 08:44 schrieb Eric S. Raymond:

> I believe you big decision is whether drop the somewjat incorrect 3.7
> branch - tip content doesn't match the tarballs.  

That's not a problem.  Almost none of our branch tip matches the last 
tarball made from the same branch, because we kept porting bug fixes 
over onto those branches, but never made a "final" release on them 
afterwards.

The converted histories I've looked at still managed to reproduce every 
single tarball we compared them to essentially perfectly, i.e. with all 
remaining differences easily explained as the result of "make dist" or 
some manual tinkering by the person preparing the release. 
cvs-fast-export found all artificial changes needed to reach these goals 
itself --- it just had to do somewhat too many of those for our tastes, 
i.e. the change sets marked as "

This splintered the initial imported set of pre-SourceForge gnuplot 
sources into three groups of files:

*) Files that were never changed at all since the import (demo *.dat 
files, almost all of them) who really still live on the vendor branch 
today (CVS revisions is 1.1.1.<n>), but are magically shifted onto the 
trunk by cvs-fast-export.

*) Files that were modified at least once before the 3.7 branch.  They 
get the vendor branch as an orphaned branch anchored at the start of git 
history, but otherwise just work fine, because nothing of interest 
happened on the vendor branch.

*) Files that were modified both on the mainline the first time after 
the 3.7 branch was started, and at least once on the 3.7 branch itself.

It's these latter one  that cause the real problem with the 3.7 branch, 
I think.  Their history has branches splitting off the vendor branch, 
and cvs-fast-export just does not handle those at all.

> In the presence of changeset comments with author attributions. Changelog
> comments are duplicative and the requirement to do them becomes increasingly
> annoying.  

I don't fully agree with that.  ChangeLog entries, at least properly 
filled-out GNU-style ones like we've been trying to do, are considerably 
more detailed than the typical git check-in comment.  They mention 
source file, function, and details of the modification.  IOW, while 
commit messages usually only describe what the goal of a change was, and 
some of the better ones also outline the implementation, they rarely 
detail how exactly that goal was achieved.  Actions like "git blame" or 
"git log" can replace some of that (and being performed locally they're 
a lot faster than "cvs annotate", too), yet I'm not sure they can truly 
replace the information content of a well-maintained ChangeLog.

It might work if we could agree that commit messages for gnuplot will be 
required to include a full ChangeLog-format block (except the header 
line) in their bottom part.  That would make it possible to generate a 
proper ChangeLog ex post, e.g. at release time.