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?

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

It does not work.  We need an actual patch parser because people put
random stuff before the actual patch, as suggested by the git am format.


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