Re: Aw: Re: Re: News spin of repository conversion

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

On 10/21/2017 03:31 PM, "Bastian Märkisch" wrote:
>> Gesendet: Samstag, 21. Oktober 2017 um 22:08 Uhr
>> Von: "Daniel J Sebald" <dan...@ie...>
>> An: "Bastian Märkisch" <bma...@we...>
>> Cc: es...@th..., gnu...@li...
>> Betreff: Re: Aw: Re: News spin of repository conversion
>>
>> On 10/21/2017 02:53 PM, "Bastian Märkisch" wrote:
>>>>
>>>> Hence, what is really happening above is a search for the first author
>>>> line that comes at or after 'changeline'.  That's not correct.
>>>>
>>>>    From step 3, I think you meant to place the test of 'n' and
>>>> 'changeline' at the front of loop and 'break' (on >) instead.  I.e.,
>>>>
>>>>        if n > changeline:
>>>>            break
>>>>        if ',' in line:
>>>>            # Multiple attributions...ignore for now
>>>>            continue
>>>>        # Deal with some address masking
>>>>        line = line.replace(" <at> ", "@")
>>>>        space = line.find(" ")
>>>>        if space < 0:
>>>>            continue
>>>> ETC.
>>>>
>>>> It should break if "n > changeline", not if "n >= changeline", because
>>>> we want to include the scenario of author info at the first changed line
>>>> (which is the most typical scenario).
>>>
>>> No quite the end of the story, though.  With that change I get 135
>>> "no time stamp matching" errors.
>>
>> I see the code that checks the date and makes sure that the date is unique:
>>
>>       if fdate in generated:
>>           continue
>>
>> However, I don't understand the requirement that the date be unique.
>> The only changes to be made for the changeset are Author and Email.  The
>> more detailed information about the SHA, commiter, etc. remains the
>> same.  Why the requirement?
>>
>> Dan
> 
> No idea. But the messages about non-matched tags come from the LONGLINES
> file.  Should have seen that in the log...
> 
> I can still identifiy a few missing and false attributions. I guess those
> could be included easily with the help of an additional input file, right?

If they look like something that should fall under the 
first-author-line-previous-to-change rule, then we should address them. 
But if due to some unique peculiar edit, then yes put those in a file. 
I'm not sure it pays to make the code have too many conditionals to 
catch corner cases, plus it becomes less generic the more unique 
circumstances addressed.

One thing I wondered about--and I'm just in the process of updating my 
utility to address this--is if somehow the first line changed is 
something other than the typical author info, e.g.,


         * src/win/wd2d.cpp:  Resize the swap chain buffers instead of
         recreating the swap chain when the window size changes.
+
+2017-07-24  Ethan A Merritt  <merritt@u.washington.edu>
+
+       * src/win/wgraph.c term/win.trm:  Default to Direct2D backend.

I can easily address that in the utility by starting not from the first 
'+' change, but from the last '+' change of the first block of '+' 
changes.  However, I'm not sure that can be done with Eric's python 
algorithm because one needs to differentiate between the addition '+', 
subtraction '-'.  The python approach only differentiates between 
modified line ('+' or '-') and non-modified line (' ').  The '+' and '-' 
come from the diff utility, which is surprisingly sophisticated.

Dan