Script to generate ChangeLog-like output from git log

  Hi, Siddhesh,

Thank you so much for doing this.  The patch looks good to me, although I
think it would be a little bit better to use the commit date, instead of
the author date, because it would make the order of the commits look a bit
more sane and it would more closely resemble what we have today.

To achieve this, you could apply the following patch on top of yours.

If you think that's nice, you have my OK to commit it with the change. If
you would prefer to have the Author Date in the ChangeLog output, I'm also
OK with it!  Thanks again!

Also, 'git am' warned that misc_util.py adds a new blank line at EOF.

---
Here's the diff I mentioned above:


---

Thanks!


On Tue, 17 Sep 2019, Siddhesh Poyarekar wrote:

>The C parser currently can identify macro definitions and scopes and
>all global and static declarations and definitions.  It cannot parse
>(and compare) changes inside functions yet, it could be a future
>enhancement if the need for it arises.

This is the fast-forward block I commented below.
It looks pretty cool to me as is, actually.

>Testing
>-------
>
>The script has been tested with the glibc repository up to glibc-2.30
>and also in the past with emacs.  While it would be ideal to have
>something like this in a repository like gnulib, that should not be a
>bottleneck for glibc to start using this, so this patch proposes to
>add these scripts into glibc.

I checked on a Fedora 30 x86_64 machine, with and without the change to
CommitDate, and the results look good to me.

>And here is (hopefully!) one of the last ChangeLog entries we'd have
>to write for glibc:

:)

>+        # Consume everything up to the ending brace of the function.
>+        (cur, loc) = self.fast_forward_scope(cur, op, loc)

Neat!  I run this with extra printfs in the code, and notice that the
whole function implementation goes into the 'contents' field, which can
later be compared by 'compare_trees'.

>--- /dev/null
>+++ b/scripts/vcs_to_changelog/misc_util.py
>
> [...]
>
>+    DebugUtil.eprint('Failed to decode: %s' % string)
>+

New blank line at EOF, as warned by git am.
  

On Fri, 20 Sep 2019, Gabriel F. T. Gomes wrote:

> Thank you so much for doing this.  The patch looks good to me, although I
> think it would be a little bit better to use the commit date, instead of
> the author date, because it would make the order of the commits look a bit
> more sane and it would more closely resemble what we have today.

Yes, use of the commit date accords with what the GNU Coding Standards say 
about the ChangeLog format ("As for the date, that should be the date you 
applied the change.").
  

On 20/09/19 9:50 AM, Gabriel F. T. Gomes wrote:
> Thank you so much for doing this.  The patch looks good to me, although I
> think it would be a little bit better to use the commit date, instead of
> the author date, because it would make the order of the commits look a bit
> more sane and it would more closely resemble what we have today.
> 
> To achieve this, you could apply the following patch on top of yours.
> 
> If you think that's nice, you have my OK to commit it with the change. If
> you would prefer to have the Author Date in the ChangeLog output, I'm also
> OK with it!  Thanks again!

Thanks, that is perfect, I've added it in and committed it.

>> +        # Consume everything up to the ending brace of the function.
>> +        (cur, loc) = self.fast_forward_scope(cur, op, loc)
> 
> Neat!  I run this with extra printfs in the code, and notice that the
> whole function implementation goes into the 'contents' field, which can
> later be compared by 'compare_trees'.

Yeah there's some cool stuff we can do with this, maybe some static
analysis on diffs to do some simple checks on the changed code.  In a
way, ChangeLog generation is sort of a stepping stone to this.

Thanks,
Siddhesh