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

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

On Friday, 17 November 2017 09:29:12 Bastian Märkisch wrote:
> > 
> > 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.
> > 
> > The remaining issue is incorrectly converted timestamp and author
> attribution.
> > I found a script that automates a recipe that is basically
> > 
> (snip)
> > 
> > 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.
> > 
> > The other alternative is to use reposurgeon during, rather than after, the
> > conversion.  Bastian was having problems with that path also.
> > 
> > 	Ethan
> > 
> 
> What I have been trying to do is to manually add author changes to the Eric
> Raymond's reconvert script.  The example command given was:
>  <es...@th...!2017-11-04T16:44:25> setfield author "Frd J. Foonly
> <fr...@fo...>"
> (which according to the docs probably should instead be
> <2017-11-04T16:44:25! es...@th...> setfield author "Frd J. Foonly
> <fr...@fo...>"
> 
> Unfortunately, such commands do not "find" the entry, not even with the tip
> version of reposurgeon.
> So I am kind of stuck for the moment.
> 
> Typical cases where this becomes necessary to correctly attribute the code
> change:
> 	* Missing ChangeLog entry to go along with the code commit (but
> maybe added later in a separate commit)
> 	* ChangeLog modifications to additional author lines that make
> reposurgeon pick the wrong line
> 	* (Copy/paste) Errors of the author / date line (incorrect date
> and/or author)
> 
> For a list of easy-to-spot candidates see e.g. the output of
> 
>     git log -i --grep  "patch.*by" --format="%aI %ae %ce %s" | awk "{ if
> (\$2 == \$3) { print \$0 } }"

That gets me 3 hits over the last 10 years, about 30 (including 20 false 
positives) going back to the turn of the century, and finally a bunch of
indirect attributions from 1998/1999.
To me that seems like a very low number of problem cases.

More to the point, are these even errors?  They correctly indicate the
original author of the patch.  If you trace a code change back to one of
these commit messages, you will indeed learn who it came from.

I had thought your concern was that there were cases where the conversion
script had mis-matched the ChangeLog entry with the corresponding set
of patches and therefore listed them as coming from whoever had made
the previous, or subsequent, log entry.  If there are such mis-matches,
it would require a different sort of search to find them.

	Ethan

> This selects all commits which have a "patch by" in the commit message but
> the committer is identical to the claimed author.  Other "suspects" can be
> found with "patch from" or "SF patch #" / "Patch #".
> All in all I so far identified <100 author attributions which could be
> amended. 
> 
> Personally, I think we should get these corrected - if reasonably possible.
> But my time at the moment is limited. Maybe locating the /commit message/ or
> the mailbox_in commands would work here, but I haven't tested that yet.
> 
>   Bastian