Re: State of the conversion

[Eric S. R. <es...@th...>]

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.

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
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.