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

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

On 11/16/2017 02:07 PM, Ethan A Merritt wrote:
> On Thursday, November 16, 2017 9:19:52 AM PST Daniel J Sebald wrote:
>> 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:
> 
> We seem to be talking past each other.
> I do not care about further tweaks to the tags or branches.
> Their conversion is sufficiently good.

Easy to do.  Modifying tags and applying changesets at other locations 
in branches is all legit stuff to do in a git repository.


> The remaining issue is incorrectly converted timestamp and author attribution.
> I found a script that automates a recipe that is basically
> 
> [from StackOverflow]

What is the link, so we may see the context?


> %%%%%%%%
> Assume for clarity of exposition that 03f482d6 is the commit
> whose author we are trying to replace, and 42627abe is the commit
> with the new author.
> 
> Checkout the commit we are trying to modify.
>      git checkout 03f482d6
> 
> Make the author change.
>      git commit --amend --author "New Author Name <New Author Email>"
> 
> Replace the old commit with the new one locally.
>      git replace 03f482d6 42627abe
> 
> Rewrite all future commits based on the replacement.
>      git filter-branch -- --all
> 
> Remove the replacement for cleanliness.
>      git replace -d 03f482d6
> 
> Push the new history (only use --force if the below fails, and only after
> sanity checking with git log and/or git diff).
>      git push --force-with-lease
> %%%%%%%%%
> 
> However I tried using this recipe to make one change and it failed.
> The filter-branch step spit out progress updates for about half an hour
> and then died.   Repository too large or too complicated?
> Some issue with branch structure that is non-fatal form most purposes
> but trips up this specific operation?
> Whatever, it doesn't work.

That doesn't seem like something one would typically want to do in a 
functioning git repo.  It's sort of getting to those real powerful but 
also baneful git commands.  One thing to keep in mind in a distributed 
source control system is it's best to not undo anything in the canonical 
version and not do anything structurally inconsistent with what other 
users have locally on their systems.  For example, after the fact 
changing authors means that other users' local git repo may no longer 
match the canonical version in a fundamental/bad way.  That is, if the 
change will mean that others will have to discard their local git repo 
and reclone the canonical version, then it should only be done in the 
most extreme and necessary cases.

Now, I see a "git commit" in the list of commands above, and git tries 
to be good about making a change of this sort as a new changeset.  But 
even the documentation raises some caveats:

https://git-scm.com/docs/git-commit#git-commit---amend

"
You should understand the implications of rewriting history if you amend 
a commit that has already been published. (See the "RECOVERING FROM 
UPSTREAM REBASE" section in git-rebase[1].)
"

I could look into this in more detail, but it sounds like an 
angels-fear-to-tread sort of thing.


> The other alternative is to use reposurgeon during, rather than after,
> the conversion.  Bastian was having problems with that path also.

If in the conversion process one wants to alter an author/committer 
entry at the very last step, i.e., "I found this particular changeset 
that should have author XYZ rather than ABC", git fast-import needs 
three files:

blob.dat
dump.dat
marks.dat

If one CAREFULLY edits the dump.dat file in a normal ASCII editor (or 
use string editor sed), one can change something like

author Lars Hecking <xxxxxx@xxxxxx> 892314000 +0000
committer Lars Hecking <xxxxxx@xxxxxx> 892669391 +0000

to

author Buster Keaton <xxxxxx@xxxxxx> 892314000 +0000
committer Lars Hecking <xxxxxx@xxxxxx> 892669391 +0000

as the very last step.  I emphasize carefully because any mismatch in 
item order or even white space will make git fast-import fail.

Dan