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

[Ethan A M. <sf...@us...>]

On Thursday, November 16, 2017 12:50:06 PM PST Daniel J Sebald wrote:
> On 11/16/2017 02:07 PM, Ethan A Merritt wrote:

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

https://stackoverflow.com/questions/3042437/change-commit-author-at-one-specific-commit/30737248

> > %%%%%%%%
> > 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.  

1) This is not typical
2) This is not [yet] a functioning git repo

We're looking for procedures  to set up a git repository in the first 
instance so that it contains a "history" of transactions that actually
happened somewhere else in a foreign language subject to faulty
translation. 

	Ethan

> 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
> 
> ------------------------------------------------------------------------------
> 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
>