Re: Roundup of GNUPLOT conversion issues

[Eric S. R. <es...@th...>]

Daniel J Sebald <dan...@ie...>:
> I'm interested in retaining history.  Why shape it into a different history
> that no one is familiar with?

Seems to me like the release tarballs are the best-known history there is.

> >We wouldn't even *want* that kind of 'perfection' - the old-style
> >change comments wouldn't play well with git log, for one thing.
> 
> Projects like Octave use FSF format
> 
> http://hg.savannah.gnu.org/hgweb/octave/rev/1680d425bb38
> 
> and it produces a nice log which highlights with color in the pager.

That isn't actually FSF format at all.  It adopts two practices the
FSF never had: (1) having a headline separated by a blank line from the
body of the comment, and (2) restricting the length of that line so it
will fit in an 80-column window with 4 leading spaces to spare.

What I sean by "old-style" is what was commonly done in CVS and
Subversion.  That is, paragraphs of running text *without* a separated
headline (and often with no internal line breaks). Those don't play
well with git.

> >It's corrupt in the sense that because of the vendor-branch confusion we
> >not only can't guarantee that the gitspace sequence of commits really
> >matches the CVS development history, we can't even get the right tip
> >state out of the conversion.
> 
> cvs2git seems to handle the vendor-branch via a branch-and-merge approach.
> (It only goes for a year or so, right?)  We'll come back to this, as I think
> it is the missing piece we need to deal with still.

Does cvs2git get the tip content of 3.7.x right - that is, coincident with the
3.7.3 tarball?

> >1. Drop the 3.7.x branch.  Replace it with a branch consisting of just
> >the archived 3.7.[0123] trees in sequence (I now have them all).
> 
> This is more work than just moving the branch to the correct location.
> cvs2git has chosen the branch point that I deduced by version/dates within
> the files, i.e., "New file."  I'll work this out.

I'm guessing you mean

<1998-04-11T19:43:11Z!lhe...@nm...>

which is the earliest commit with a "New file." comment. The commands you want
would probably be 

/Initial import of 3.6 beta340./ assign root37
@min(/New file.$/),<root37> reparent --use-order --rebase

except I suspect you want to sctually do this:

/Windows linestyle fix/ assign root37

and then lose the preceding reimports.

> >3. Fill in the empty log comments that are left.
> 
> We'll see if Ethan wants to do this.  He and I can split the work, but only
> if it is something easy to do with reposurgeon.

You two don't have to drive reposurgeon st all to do this.  Just fill in
comments in the enclosed file and send it back to me.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.