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

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

On 11/16/2017 10:37 AM, sfeam wrote:
> On Thursday, 16 November 2017 04:23:58 Daniel J Sebald wrote:
>> On 11/16/2017 12:17 AM, sfeam via gnuplot-beta wrote:
> 
>>> cvs->git conversion
>>> ===================
>>>
>>> A snapshot of the cvs repository from 04-November-2017 was converted
>>> to git with the help of Eric S Raymond [Thanks!]
>>> Since then we have been evaluating the state of the converted source tree.
>>> At the moment there are two copies on sf.net, one slightly cleaner than
>>> the other.  A handful of commits have gone in to these, but it remains
>>> true that the existing git content on sf.net may be wiped clean and
>>> re-created from the 04-Nov-2017 snapshot if we find that there were
>>> annoying but correctable errors from the previous conversion[s].
>>> So far the "correctable" part has been a sticking point.
>>>
>>
>> I've sent a script file in a previous post that can be used to compare
>> CVS versions to git versions, about two dozen of them.  One can see
>> precisely what the differences are (almost all log/RCSid related).  I
>> described in detail the major discrepancy I've found surrounding version
>> 4.6.3 in a previous post.
> 
> Do you have a script to correct those discrepancies?
> As I tried to imply, it's the correction stage that seems to be hard.

No script (I thought that git conversion was already complete, that's 
why I put SHAs in the sample commands).  Here are steps (all very 
simple) that can be done after the conversion is complete:

"
Given that, it looks like you'll need to add something there to get 
release 4.6.3 in line with the tarball.  And the easiest thing is 
probably to mimic what cvs2git did as follows:

1) Create a branch from "bump patchlevel to 4.6.3" version

git checkout c21a99aa6caecac5f125219e791665953c816b37
git checkout -b Release_4_6_3_tarball_stub (or some similar name)

2) Merge changeset "fix memory allocation for large matrices" to the 
newly created stub branch:

git cherry-pick 7d0989dd8cf3b3c18a1fa7181c8a1d38ab14d0b3

3) Change the tags as follows (where the indentation means a different 
branch, however the viewer chooses to display the graph):

       [4.6.3] fix memory allocation for large matrices    Ethan A Merritt

[4.6.3-Windows] fix memory allocation for large matrices    Ethan A Merritt
Release 4.6 patchlevel 3            Bastian Maerkisch
bump patchlevel to 4.6.3                    Ethan A Merritt
*** empty log message ***                   Ethan A Merritt

That is, delete tag [4.6.3] and add a new tag [4.6.3] on the new branch 
(stub) which has the patch.  This puts version tagged [4.6.3] in line 
with cvs-repository and the tarball.  Add a new tag [4.6.3-Windows] to 
signify that is the release that Bastian has published for 4.6.3 that 
includes everything in the 4.6.3 tagged version plus the mods to four 
Windows-related files.
"


>>> Questions
>>> =========
>>>
>>> I'm still learning how to rethink my work flow for git, so please
>>> help me out.   For instance, does it make any sense to continue
>>> to maintain the ChangeLog file?   So far I'm having little success in
>>> keeping it in sync with the git commit messages.  Is there some
>>> tool to help with that, or is the normal practice with git to rely
>>> only on the commit messages?  I know you can dump a log of commits,
>>> so I guess one possibility is to use that to update the ChangeLog every
>>> now and then (1 month intervals? 6 months?) but not try to touch it
>>> for every commit.  Advice?
>>
>> That's possible, but after a month of using git you'll likely wonder,
>> Why update a ChangeLog?  Typing "git log | less" is just as easy as
>> "less ChangeLog" and the git command works in all subdirectories.
> 
> That will only take you back as far as the cvs->git conversion date.

I know.  When this conversion began, I immediately brainstormed on ways 
we might incorporate all the historic ChangeLog info into a "git log" 
printout.  That idea was rejected, probably for the better because 
chronological order could not be maintained exactly.


> When trying to track down a bug I often need to hunt back all
> the way into the version 4 development series.  That history is captured
> in the ChangeLog files but so far as I know is never going to be retrieved
> by a git command.

That's why I suggested not removing the ChangeLogs entirely from the 
repository but instead keeping them handy by moving them into some 
folder "historic_cvs" which obviously indicates that workflow is no 
longer in use, because it is otherwise cumbersome to checkout an old 
version of code just to retrieve the historic ChangeLog files.  Plus 
some people are used to using "grep" for searching and grep is always 
nice (it's effectively the same as qgit's funnel search feature).

But if you want to maintain a ChangeLog, then don't do that.  However, 
certainly having the current ChangeLog workflow in the git commit 
message itself has the advantage of quick searching within qgit 
(definitely want that).  In any case, maintaining the same info in 
different places is always fraught with inadvertently going out of synch.


> The existing conversion does not turn the old ChangeLog
> text into commit messages so "git log" won't see them.
> Or maybe I'm missing some clever search command other than "git log"?

qgit allows fast funnel searching on Author, SHA, log message, etc.  But 
there is also a slower search of the whole repository diff hunks.  So if 
one is very detailed about the historic ChangeLog phrases to search for, 
matches will appear in one of the diff hunks for the ChangeLog file 
itself.  So, searching the historic ChangeLog is still possible, but 
probably in a much more roundabout way.

Dan