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

[sfeam <sf...@us...>]

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.
 
> > 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.
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.  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"?

	Ethan
 
> Keep the same format for the git log messages as you've been using for 
> the ChangeLog, i.e.,
> 
> -> One line of "short-log"
> -> List of files that have changed, just like CVS ChangeLog entries
> 
> After you are used to git, move the ChangeLog files to some subdirectory 
> "historic_cvs" or something.  The entries still apply to the history, 
> and the ChangeLog files can be searched but in a more cumbersome way 
> than using gitk/qgit/gitg funnel searching.  If you are happy with just 
> looking at the diffs in the ChangeLog for every commit in the git 
> repository, then deleting the ChangeLogs from the master is fine too. 
> Somehow I think it is better just tucking the ChangeLog files in some 
> subfolder.
> 
> You'll need to come up with a work flow that incorporates what tools you 
> are used to, e.g., any special editor for looking at patch files, etc. 
> Things to keep in mind.
> 
> 1) Ask the people submitting patches, via their git tools to include the 
> file change info in their log messages, using the existing git 
> repository changesets as examples.
> 
> 2) Code submitters will generate their changeset and extract it into a 
> patch file, changeset header and all.
> 
> 3) One option is to apply that patch to your local repository and test. 
> If you feel the patch is good, then push to the canonical version.  If 
> it isn't quite ready, you'll have to learn how to reset your local copy 
> (i.e., toss out the applied changeset).
> 
> 4) Say you aren't quite happy with the code in the changeset, but it is 
> close or you want to clean up the person's changeset log message.  One 
> option is to edit the changeset/patch file directly.  Sometimes 
> convenient, but sometimes not if it is a complex change.
> 
> 5) The changeset file that people submit will look exactly like a 
> typical patch file, except at the top will be extra git SHA, author 
> info, log message, etc. in "comments" section.  So, another option is to 
> not import the submitter's changeset, but instead just use the normal 
> "patch" command as you are used to.  (You may need -p0 or -p1 in the 
> patch command to get rid of that first level a/ and b/ that git puts in 
> place.)  Hit the reset button within git-gui, gitg or qgit, and you will 
> then see the changes that the submitter is proposing.  This then makes 
> the workflow something very similar to the way you would go about your 
> own changesets.  But then you'll need to learn how to commit the 
> submitters changes and supply the author info from the submitters patch 
> file.
> 
> 6) Remember all of this is local, so if you make a mistake only 
> recognized after doing a commit, you can easily reset that commit back 
> to the staged file status prior to the erroneous commit and redo with 
> corrections.  Or, you may discard all changes with "git checkout".  Once 
> you have one or more changesets that you are satisfied with locally, 
> then use "git push" to put them in the canonical repository.
> 
> 7) You are going to eventually run into cases in which the commit that 
> you make and push to the canonical repository will conflict with some 
> changeset that another developer pushed, e.g., you edited some of the 
> same files and same code lines as another user.  That is, the diff-hunks 
> of the changesets interfere with one another.  Git tries its best to 
> merge, but sometimes it is confused and you'll have to manually tell git 
> how to resolve conflicts.  You'll need a merge tool for best 
> visualization of exactly what's happening.  KDE might have a merge tool 
> already setup, or look for "meld" which is pretty nice.
> 
> Dan
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta