Re: Update on the branch surgery

[Daniel J S. <dan...@ie...>]

On 10/25/2017 11:36 PM, sfeam via gnuplot-beta wrote:
> On Thursday, 26 October 2017 00:06:43 Eric S. Raymond wrote:
>> The alternatives remain as follows:
>>
>> If it were my call, I'd cut our losses - just drop the 3.7.x and 4.0
>> branches entirely.  That would leave the repo in a very clean state where
>> we have confidence that what is there matches its actual development
>> history quite closely.
> 
> OK by me.

I think the 3.7/4.0 branch stuff is fine, and I think I have a pretty 
good guess at the historical process of releases.  There are a couple 
issues that need resolving (the 3.7.0 tag and the master branch at the 
start), but I'll come back to that.  And I have a suggestion for easily 
rectifying near the end.

As I had done with git-translate changeset "Windows linestyle fix." and 
CVS GNUPLOT_RELEASE_3_7_0, I've done a directory-by-directory comparison 
of git-translate tag 3.7.1 and CVS GNUPLOT_RELEASE_3_7_1.  I've found 
the code to very close, so much so that I trust the changeset history on 
that 3.7.x branch.  I.e.,

cd gnuplot
cvs update -rGNUPLOT_RELEASE_3_7_1
cd ..
git -C branch_reference checkout 77be49b3e61284eb0e3d9d74064c207390cc5565
diff -ur --exclude=".git" branch_reference/ gnuplot/ > 
GNUPLOT_RELEASE_3_7_1_vs_gtag_3.7.1.diff

The diff file is big, so I'm going to email it to just a few folks.  But 
I'll pull out the useful information for explaining what I think was done.

1) The bulk of the diffs between the CVS and git 3.7.1 are of the 
following category:

diff -ur '--exclude=.git' branch_reference/alloc.c gnuplot/alloc.c
--- branch_reference/alloc.c	2017-10-25 16:05:19.146473811 -0500
+++ gnuplot/alloc.c	2017-10-26 00:18:13.471555544 -0500
@@ -1,5 +1,5 @@
  #ifndef lint
-static char *RCSid = "$Id: alloc.c,v 1.12 1998/03/22 22:31:16 drd Exp $";
+static char *RCSid = "$Id: alloc.c,v 1.1.1.2 1998/04/15 19:21:56 
lhecking Exp $";
  #endif

  /* GNUPLOT - alloc.c */

I'm not too worried about the mismatch, but HBB might have an 
explanation as to why the 1.1.1.2.  I think it might be due to branching 
in order to create a little stub for the purpose of a release candidate 
and tarball.  More later.

2) Here is a list of the files that exist in one directory and not the 
other:

sebald@ ~/gnuplot/git_translation/branch_point_search $ grep -i "only 
in" GNUPLOT_RELEASE_3_7_1_vs_gtag_3.7.1.diff

Only in gnuplot/: config
Only in gnuplot/: CVS
Only in gnuplot/demo: CVS
Only in gnuplot/demo: games
Only in gnuplot/demo: html
Only in gnuplot/demo: plugin
Only in gnuplot/docs: CVS
Only in branch_reference/docs: latextut
Only in gnuplot/docs/old: CVS
Only in gnuplot/docs/psdoc: CVS
Only in gnuplot/docs: windows
Only in branch_reference/: .gitignore
Only in gnuplot/m4: CVS
Only in gnuplot/: man
Only in branch_reference/: NeXT
Only in branch_reference/: os2
Only in gnuplot/: pm3d
Only in gnuplot/: share
Only in gnuplot/: src
Only in gnuplot/term: CVS
Only in gnuplot/term: js
Only in gnuplot/term: lua
Only in gnuplot/term: PostScript
Only in gnuplot/: tutorial
Only in gnuplot/win: CVS

Most of the above look like empty directories of CVS.  We don't care 
about those not being in the git repository because there is no code 
loss associated with that.  On the other hand, the directories in git 
repository 3.7.1 *do* contain something:

sebald@ ~/gnuplot/git_translation/branch_point_search $ ls 
branch_reference/docs/latextut/
eg1.plt  eg3.dat  eg4.plt  eg6.plt     linepoin.plt  Makefile.in
eg2.plt  eg3.plt  eg5.plt  header.tex  makefile.dst  tutorial.tex

sebald@ ~/gnuplot/git_translation/branch_point_search $ ls 
branch_reference/NeXT/
bigger.tiff         GnuTerm_main.m       GnuView.m           PB.project
Controller.h        GnuTerm.tiff         Makefile            README.rtf
Controller.m        gnuviewController.h  Makefile.postamble  smaller.tiff
English.lproj       gnuviewController.m  Makefile.preamble
GnuTerm.iconheader  GnuView.h            PB.gdbinit

sebald@ ~/gnuplot/git_translation/branch_point_search $ ls 
branch_reference/os2
dialogs.c  gclient.c    gnupmdrv.c    gnupmdrv.h    gnupmdrv.rc
dialogs.h  gnuplot.ico  gnupmdrv.def  gnupmdrv.ipf  print.c

Those are all files that are missing from the CVS (tarball) version.  My 
suspicion is that at the time whoever created the release/tarball 
figured there was no point in including these files so discarded them 
(on a stub branch).

3) Now, the difference in code between these two versions:  I'm going to 
attach those as short file.  All the changes are related to version 
numbers and dates, except this one:

--- branch_reference/term/tgif.trm	2017-10-25 16:05:19.310473813 -0500
+++ gnuplot/term/tgif.trm	2017-10-26 00:18:18.307555592 -0500
[snip]
state(%d,30,%u,0,0,%u,16,1,9,1,1,0,0,0,0,1,0,'%s',0,%u,0,0,1,10,0,0,1,1,0,16,0,0,1,1,1).\n\
-%%\n%% @(#)$Header: 
/export/home/cheetah/ddenholm/cvsroot/gnuplot/term/tgif.trm,v 1.66 
1998/04/14 00:18:10 drd Exp $\n%% %%W%%\n%%\n\
+%%\n%% @(#)$Header: /cvsroot/gnuplot/gnuplot/term/tgif.trm,v 1.10 
1998/12/16 19:48:20 lhecking Exp $\n%% %%W%%\n%%\n\

I suppose Lars recognized this computer-specific reference at the last 
minute and changed it.  Could it also be that because Lars pulled the 
CVS code onto his machine that the "$Id:" references were changed from 
drd (ddenholm) to lhecking?

My theory on the difference between CVS version GNUPLOT_RELEASE_3_7_1 
and version git tag 3.7.1 is that the current git tag 3.7.1 is not the 
actual "release" that created the tarball.  It's just prior to the 
release, and Lars created a branch off the 3.7.x series at what would be 
tag 3.7.1 that was probably one checkin long, i.e., a short stub the 
purpose of which was to update version/date, clean up various things and 
toss away files from the release that wouldn't be used by anyone (i.e., 
tutorial manual, NeXT, os2).

In other words, the release is just a short little stub off of the 3.7.x 
branch.  Perhaps reposurgeon can't resolve a one-checkin branch (i.e, 
stub).  It may be that all the 3.7.x releases and perhaps the 4.0.0 
release were done this way.  (It wouldn't surprise me that 4.0.0 was 
released from the 3.7.x series and then some kind of merging of all mods 
into master branch.)

Anyway, technically the git tag 3.7.1 is not the actual release.  Here's 
how I propose to resolve this.  After the repository is translated, 
Ethan can, as a first item of action in git,

1) Checkout git tag 3.7.1 and create a branch
2) In some other directory checkout out cvs GNUPLOT_RELEASE_3_7_1
3) Clean the files out of the git directory tree and replace them with 
the files from the cvs directory.
4) Create a git commit from those changes.  (Something like qgit will 
highlight the files that are added, that are missing, and that have 
changed, and Ethan can click the little boxes to stage them into the 
commit.)
5) Remove the git 3.7.1 tag from the branch point and create a new 3.7.1 
tag at the changeset just committed.

So, it's effectively recreating history and we'll have a the 
code/version we want.  We'll do that with the other 3.7.x series branches.

...

OK, now the two things I feel are unresolved.

1) We need to figure out where CVS GNUPLOT_RELEASE_3_7_0 corresponds to 
the git master branch changeset, and create a tag 3.7.0 for that.  That 
will also be the grafting point for the 3.7.x series branch.

2) The master branch point in the attached screenshot of qgit originates 
from before beta340, beta343, etc.  I wonder if master branch should 
instead start at the point where all the other branches in that 
screenshot are emanating.  The point prior to import of beta340, etc. 
would be "Initial revision".

Dan