This is the mail archive of the
mailing list for the glibc project.
Re: Hash out a solution for ChangeLog/NEWS at the Cauldron?
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: <libc-alpha at sourceware dot org>, <carlos at redhat dot com>, <roland at hack dot frob dot com>
- Date: Wed, 5 Aug 2015 14:22:17 +0000
- Subject: Re: Hash out a solution for ChangeLog/NEWS at the Cauldron?
- Authentication-results: sourceware.org; auth=none
- References: <20150804173912 dot GC2504 at spoyarek dot pnq dot redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1508041743390 dot 10621 at digraph dot polyomino dot org dot uk> <20150805002648 dot GE2504 at spoyarek dot pnq dot redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1508051104360 dot 7214 at digraph dot polyomino dot org dot uk> <20150805114952 dot GL2504 at spoyarek dot pnq dot redhat dot com>
On Wed, 5 Aug 2015, Siddhesh Poyarekar wrote:
> > I don't see the point in a [committed] message if only the log message has
> > changed.
> Any change in the content of the patch, including the commit log and
> even the date and time will result in the commit id being changed.
> patchwork identifies patches based on their commit ids, so a changed
> commit id means that the patch does not get marked.
An emailed patch doesn't have a commit id, assuming you mean the SHA1 hash
of the commit object generated by git; that depends on the committer email
and date, not just the author email and date, as well as the complete
state of the patched tree (not just the files modified by the patch) and
the parent commit objects. For changes not involving the actual diff
itself I'd rather leave it to people to see the final commit on glibc-cvs
(and have the committer update patchwork manually if it can't be smarter
about detecting what's the same change) rather than having extra emails to
the list just for the sake of controlling patchwork.
Joseph S. Myers