Re: State of the conversion

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

On 10/13/2017 01:21 PM, Eric S. Raymond wrote:
> Daniel J Sebald <dan...@ie...>:
>> On 10/13/2017 07:56 AM, Eric S. Raymond wrote:
>>> You haven't heard from me in a couple of days because I decided to
>>> build a ChangeLog parser into reposurgeon and have been working on
>>> that.
>>>
>>> It's not an easy problem, and I have doubts that the information
>>> extracted that way will either cover a lot of commits or be of
>>> useful quality.
>>
>> I have done such a thing with the post git-converted repository already.
>> Code is here:
>>
>> https://sourceforge.net/p/gnuplot/patches/763/
>>
>> I believe it is rather accurate, more accurate than the method you are
>> describing which attempts to pull info from the ChangeLog entries alone.
>>
>> The methodology in the link above has the added, important detail
>> (particular to the gnuplot project) of working from the diff hunks of the
>> ChangeLog file itself for every git-translated changeset.  It hinges on the
>> fact that Ethan, et al. have consistently modified the proper location in
>> the ChangeLog file for every CVS modification they've made. It's that action
>> over the years which makes it accurate, i.e., the method traces the
>> incremental changes made by the maintainers.
>>
>> Parsing the ChangeLog on its own won't work very well because, as I pointed
>> out, the entries have been generated piecemeal.  Ethan, et al. would often
>> make a mod that goes back several days or possibly weeks pertaining to some
>> checkin attributed to various contributors. Chronological order is not
>> maintained; the mod maintainers make can be weeks apart from the date listed
>> in the ChangeLog entry.
>>
>> That's why relying on the particular mod the maintainers made is better.
>>
>> The utility generates a list similar to the following:
>>
>> 87ca52fd56cf60be023642ad2664390affd5d896 2017-09-03 Daniel J Sebxxx
>> <xxxxxx@xxxxxx>
>> 778fe3d377116dc6d8c4f855372795bea5339e62 2017-09-03 Ethan A Merrxxx
>> <xxxxxx@xxxxxx>
>> c67c414e1604b20c562451ca6a2d6e9dca71561f 2017-09-02 Ethan A Merrxxx
>> <xxxxxx@xxxxxx>
>> 357f0cf68d691f3f76aade64053a6791f2e28686 2017-09-01 Bastian Maerkixxx
>> <xxxxxx@xxxxxx>
>> 984f9ad6c62f1c3ade9a41b46b5e034a2cb01c0a 2017-08-31 Martin Satuxxx
>> <xxxxxx@xxxxxx>
>> a0b903cbcae615cef9c0c0e3942c78ab150e3c82 2017-08-24 Ethan A Merrxxx
>> <xxxxxx@xxxxxx>
>>
>> I pointed out in a previous email that the date in the above list is of no
>> value for the git repository.  There will not be good correlation between
>> the date above and the actual date of the git changeset associated with
>> 87ca52fd56cf60be023642ad2664390affd5d896, for example. All that needs to be
>> done is some automated git command that will associate the author
>> information in the above list with the gitID changeset in the list.
> 
> I see your point.  Unfortunately, I can't integrate this technique into
> my conversion pipeline as-is, because
> 
> (a) it relies, as you note, on a regularity in metadata specific to your
> project, and
> 
> (b) My tools know nothing about SHA-1 IDs!  Those are specific to an
> instantiated repository's hash chains.

Yes, it's particular to the repository; no transferring of lists across 
platforms, conversions, etc.


> However, there may be a way around this.
> 
> Can you generate your report with the hashes replaced by action stamps?
> 
> An action-stamp is a kind of commit ID my tools understand.  It has
> this form:
> 
> <committer-id!yyyy-mm-ddThh:mm:ssZ>
> 
> That is, it consists of a committer ID email address, followed by an
> RFC3339-format representation of the commit date.
> 
> These are not necessarily unique per repository, but they usually are.
> 
> This command will generate an action stamp from a SHA-1 ID:
> 
> git log --format='<%cE!%cIZ>' -1 $1

Oh, OK.  Yeah, I've found a command that does it without even having to 
change the code (posted at the patch-tracker):

git log --format='commit <%cE!%cIZ>' -p --unified=50 ChangeLog > 
ChangeLog.diff
git_changelog_author ChangeLog.diff > author.txt

The "commit" in the first column is what the utility is searching for. 
So the list then looks like this:

<sfeam!2017-09-04T05:57:37+00:00Z> 2017-09-03 Daniel J Sebxxx 
<xxxxxx@xxxxxx>
<sfeam!2017-09-03T23:28:50+00:00Z> 2017-09-03 Ethan A Merrxxx 
<xxxxxx@xxxxxx>
<sfeam!2017-09-03T03:35:30+00:00Z> 2017-09-02 Ethan A Merrxxx 
<xxxxxx@xxxxxx>
<markisch!2017-09-01T05:21:00+00:00Z> 2017-09-01 Bastian Maerkixxx 
<xxxxxx@xxxxxx>
<sfeam!2017-08-31T23:03:55+00:00Z> 2017-08-31 Martin Satuxxx <xxxxxx@xxxxxx>
<sfeam!2017-08-30T20:30:12+00:00Z> 2017-08-24 Ethan A Merrxxx 
<xxxxxx@xxxxxx>

which has the person who committed the changeset and author.  Nice.

Dan