When can we stop writing ChangeLogs?

[Florian Weimer]

* Joseph Myers:

> On Mon, 30 Sep 2019, Florian Weimer wrote:
>
>> I'm looking for something far simpler here—a script that submitters and
>> reviewers can run to see what's going to be committed, and some level of
>> project consensus that this is how patches should be posted.
>
> I suggest that should be "git am", as an existing known format for email 
> patch submissions, for any case except where the patch has already been 
> committed (and really "git am" format could probably be used there as 
> well), the patch would be excessively large (whether because of large 
> generated files or otherwise) or the patch contains mixed character sets 
> which require it to be attached in compressed form to avoid it being 
> mangled.  We can discuss details regarding e.g. scissors lines, but I 
> think we should still aim for patch submissions that are valid for "git 
> am" in some form - and in particular, that use "git am" markings to 
> separate the commit message from other remarks (e.g. differences between 
> revisions of the patch) that are not intended as part of the commit 
> message.

I'm fine with “git am” input, as long as there is a reliable way to
extract the commit, as it would be committed if you had a matching tree.
I do not want to go hunting for the matching in every case, particularly
for a series of patches.

Do you think that the attached script might work?

I don't want to invoke filterdiff in place of the awk script because
filterdiff is known to garble some git-style patches:

  <https://bugzilla.redhat.com/show_bug.cgi?id=1585063>

Thanks,
Florian
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: glibc-show-patch
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20191001/43086e18/attachment.ksh>