Re: Release timestamps for archaic tarballs

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

On 10/14/2017 01:15 PM, Eric S. Raymond wrote:
> I'm making good progress on the git conversion procedure.  I expect to
> have it wrapped up and ready to go tonight or tomorrow.  All I will
> need to pull the trigger at that point is
> 
> (a) Daniel Sebald's authorship map.

Eric,

Generating the authorship map file requires a git repository (from the 
frozen CVS repository).  If you are not using the map after the 
cvs-to-git conversion, but during the conversion, then there will be a 
three-step process: generating the git repository, generating the 
authorship map, and re-generating the git repository.

If you provide the git repository from the frozen CVS repository, I can 
clone the repository and generate the authorship map then post that file 
somewhere.  Alternatively, you can compile the utility and follow the 
directions described in "git_changelog_author --help".

Let me describe the algorithm, for Ethan's benefit, then give an example.

The utility is quite simple.  It's main approach is: for each changeset 
where there is a modification to ChangeLog

MAIN ALGORITHM:

Search for the first change in ChangeLog diff-hunk.  From that point 
search backward for the first authorship line (which typically is the 
current line because a new FSF entry is being added to the ChangeLog).

EXCEPTIONS:

1) The authorship line cannot be a subtraction, i.e., can't have a minus 
sign as the first character.  The reason is that is typically a scenario 
with a wholesale swap of the ChangeLog file, for example if ChangeLog is 
renamed ChangeLog.1 and a new blank ChangeLog is created, or it might be 
a corrected authorship line.  Such situations are left attributed to the 
committer, usually Ethan (sfeam).

2) If the ChangeLog file is the *only* file that changes in the 
changeset, it is left out of the authorship map file.  These are 
typically cases where Ethan goes back to clean up some comments.  In 
such scenarios it is likely that the above algorithm searches backward 
to some FSF author line that really isn't pertinent.  It might make 
sense in some cases because it goes back to the original author.  But it 
could also be random.  My thinking is that it is best to leave clean-up 
modifications attributed to the committer.

To my way of thinking, the one problem this won't catch is where the 
original ChangeLog entry had an error in the authorship line itself and 
then Ethan went back and corrected the authorship line, because such a 
scenario will have '-' in the first column of the first changed line and 
a '+' in the first column of the second changed line.  This is 
discarded, hence the original incorrect authorship (misspelled, wrong 
email, whatever) will remain in the authorship map.  If such a scenario 
exists in the map and someone finds the uncorrected authorship in the 
future, as Mojca pointed out, that can be fixed by hand.

An example with the test repository that Mojca generated.  First step is 
create the lists from the "git log" command.  Second step is process 
those lists to create the authorship map, in one case not extracting 
ChangeLog-only changeset and in another case extracting such changesets:

sebald@ ~/test_repository $ git log --format='commit <%cE!%cIZ>' -p 
--unified=50 ChangeLog > CL.diff
sebald@ ~/test_repository $ git log --format='commit <%cE!%cIZ>' 
--name-only > files.lst
sebald@ ~/test_repository $ git_changelog_author CL.diff > author1.txt
sebald@ ~/test_repository $ wc author1.txt
   6037  32500 536364 author1.txt
sebald@ ~/test_repository $ git_changelog_author CL.diff files.lst > 
author2.txt
sebald@ ~/test_repository $ wc author2.txt
   5632  30391 500619 author2.txt

I used word-count utility to check how many lines are in each file. 
What the above is telling us is that there are 6037 changesets in which 
the ChangeLog was modified in which '-' was not in the first column of 
the authorship line.  Of those, 405 (i.e., 6037 - 5632) changesets 
involved only the ChangeLog.

Dan