This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: When can we stop writing ChangeLogs?

* 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:



Attachment: glibc-show-patch
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]