Subject: Re: [Bug-vc-dwim] bug#38862: attribution line parsing
From: Jim Meyering <[email-masked]>
To: Karl Berry <[email-masked]>
Cc: [email-masked]
Date: Fri, 3 Jan 2020 22:01:38 -0800
List-Id: <debbugs-submit.debbugs.gnu.org>

On Wed, Jan 1, 2020 at 6:44 PM Karl Berry <[email-masked]> wrote:
> Hi Jim - When I had only a single space between date and name in the
> attribution line, as in:
>
> 2020-01-01 Karl Berry  <[email-masked]>
>
> vcd gave no errors by default. Then I accidentally ran vcd --commit with
> that CL and the only error (warning) was at the end, direct from Perl:
>
> Use of uninitialized value $author in sprintf at /u/karl/gnu/src/vkarl/VC.pm line 210.
> Use of uninitialized value $author in sprintf at /u/karl/gnu/src/vkarl/VC.pm line 210.
>
> I was not left in a good state.  There seemed to be no good way to
> recover from this, since the erroneous ChangeLog was already committed,
> so vcd did not think there were any files in the ChangeLog lines.
>
> So I ended up doing rm -rf .git/c/.git and running vcd --init again to
> restart my CL repo, and also
>   git fetch && git reset --hard origin && git checkout && git submodule update
> to eradicate all my changes (after saving the actual diff :) in the
> source repo. Thankfully, that apparently erased the memory of the bad CL
> so I could proceed.
>
> Instead of worrying about the exact number of spaces, I wonder about
> parsing attr lines by checking that first word is a YYYY-MM-DD date, the
> last word is <[email-masked]>, and considering the words in between to be
> the real name.
>
> Reasonable error msgs would then be easy to give if the first and last
> words don't fit the expected syntax.  And if there is no author, it
> could give up at that point. After all, vcd relies on all kinds of
> finicky details about the CL, so seems like it might as well force a
> good attr line too instead of accepting bad ones.
>
> If the idea seems ok, maybe one of us (or a new contributor!) can work
> in that direction eventually. --best, karl.

Hi Karl,
Thanks for reporting and digging into that.
Here's the change that I've just pushed to address it: