Re: Update on the branch surgery

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

On 10/26/2017 12:39 PM, Ethan A Merritt wrote:
> On Thursday, October 26, 2017 9:50:20 AM PDT Daniel J Sebald wrote:
> 
>>> The incorrect date comes from a typo in the ChangeLog.
>>>
>>>     https://sourceforge.net/p/gnuplot/git-main/ci/50bc9c8abfd499a56717cc
>>>     f324434bdc675e2bea/>
>>> Note, however, that typo is not present in the main branch copy of
>>> ChangeLog (actually ChangeLog.1) because it was later corrected.  That
>>> leads me to wonder which era of the ChangeLog text you guys are mining
>>> to assign dates during the git conversion.
>>
>> We aren't using any changelog file.  What we are looking at is the
>> *changes* to ChangeLog as they are associated with the changes in other
>> files.  That is, every time something was checked into CVS there was
>> always a small change to the ChangeLog file as well.  That trail
>> contains the most information.  So, if there was a typo in the ChangeLog
>> entry for a particular checkin, that mistaken date ends up in the git
>> changeset.
>>
>> It's not possible to look at a whole ChangeLog file and infer dates and
>> times about myriad checkins because that ChangeLog was constructed in a
>> piecemeal fashion, placing an item under some entry days prior, editing
>> some past entry, placing a new entry before other entries rather than
>> the top of the file, etc.
>>
>> The typo explains the date discrepancy (thanks).  There's going to be a
>> few of those.  After the fact we can attempt a simple rebase/correct and
>> if it works, fine, if not just live with those sorts of issues.  That's
>> the minor concern aside from getting the graft points correct.
>>
>> Dan
> 
> Huh.
> On the one hand, that makes sense.
> On the other hand there must also be a CVS check-in date for that change.
> Why would you trust the text field in the ChangeLog more than the
> check-in date?

We do trust the check-in date; that becomes the commit timestamp in the 
git repository.  What we are trying to reconstruct is the correct Author 
and author timestamp.  That's why in qgit, etc. the changeset is in the 
correct order, but the author date jumps around a bit (e.g., five days 
prior, one day prior, etc.).

The way it will work with git is that non-maintainer developers will 
create changesets locally for bug fixes.  Then they'll export that 
changeset and post to the bug tracker.  In that ASCII file will be the 
Author and author date/time information.  When the maintainers accept 
that change, they'll commit the changeset (perhaps with some minor 
tweaks to commit message and code), then push to the canonical 
repository.  The maintainer's info will be listed in Committer, while 
the original author will be listed in Author.  Mercurial has the same 
approach, see for example

http://hg.savannah.gnu.org/hgweb/octave/

where the author dates can be months behind the commit dates.

This will save maintainer's time because the responsibility of the FSF 
"ChangeLog" message will now fall upon the original author, for the most 
part, and no more ChangeLog to maintain.

Dan