Could we please have a gcc-cvs-patches list, with all patches automatically sent to it exactly as they are committed to CVS? Release: 2.97 20010112 (experimental) Environment: System: Linux decomino 2.2.18 #1 Sun Jan 7 21:04:55 UTC 2001 i686 unknown Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu configured with: ../gcc-cvs/configure --prefix=/opt/gcc/snapshot --disable-shared --enable-threads=posix --with-system-zlib How-To-Repeat: Observe bogus changes in a commit not covered by the ChangeLog entry or commit message, that could be more quickly detected if an automatic mailing of committed patches were available.
Fix: Adapt the machinery that creates the gcc-cvs messages to also create gcc-cvs-patches ones. These should include proper diffs for added / deleted files, and for files that diff counts as binary; I suggest -uapN as suitable GNU diff options, with the patch getting gzipped and uuencoded if it is very large or passes some tests indicating it might get corrupted in mailing (contains control characters other than newline / tab / form feed or very long lines).
From: Zack Weinberg <zack@codesourcery.com> To: "Joseph S. Myers" <jsm28@cam.ac.uk> Cc: Nathanael Nerode <neroden@twcny.rr.com>, <gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org> Subject: Re: other/1634: Request for gcc-cvs-patches list Date: Sat, 11 Jan 2003 12:51:56 -0800 "Joseph S. Myers" <jsm28@cam.ac.uk> writes: > On Sat, 11 Jan 2003, Nathanael Nerode wrote: > >> To what extent is this request superseded by the links in gcc-cvs messages to >> the cvsweb pages giving precisely the corresponding patches? > > It isn't. Following hundreds of links a day of the offchance that one > might be wrongly reverting something or wrongly committing something isn't > a reasonable solution to the problem. The idea of this wishlist request > is that the patches themselves go by in email - exactly as committed, > which may differ from how they were sent to gcc-patches, or they may not > have been sent to gcc-patches - for bogus reversions, or bogus changes > (e.g. other changes in the same tree that weren't part of the given patch > and shouldn't have been committed) to be spotted. Also so that years later it is easy to get hands on the complete change committed to CVS as a unit, for backporting or whatever. zw
From: Nathanael Nerode <neroden@twcny.rr.com> To: gcc-gnats@gcc.gnu.org, jsm28@cam.ac.uk, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org Cc: Subject: Re: other/1634: Request for gcc-cvs-patches list Date: Sat, 11 Jan 2003 14:36:56 -0500 To what extent is this request superseded by the links in gcc-cvs messages to the cvsweb pages giving precisely the corresponding patches? --Nathanael
From: "Joseph S. Myers" <jsm28@cam.ac.uk> To: Nathanael Nerode <neroden@twcny.rr.com> Cc: <gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org> Subject: Re: other/1634: Request for gcc-cvs-patches list Date: Sat, 11 Jan 2003 20:33:48 +0000 (GMT) On Sat, 11 Jan 2003, Nathanael Nerode wrote: > To what extent is this request superseded by the links in gcc-cvs messages to > the cvsweb pages giving precisely the corresponding patches? It isn't. Following hundreds of links a day of the offchance that one might be wrongly reverting something or wrongly committing something isn't a reasonable solution to the problem. The idea of this wishlist request is that the patches themselves go by in email - exactly as committed, which may differ from how they were sent to gcc-patches, or they may not have been sent to gcc-patches - for bogus reversions, or bogus changes (e.g. other changes in the same tree that weren't part of the given patch and shouldn't have been committed) to be spotted. -- Joseph S. Myers jsm28@cam.ac.uk
From: "Joseph S. Myers" <jsm28@cam.ac.uk> To: Zack Weinberg <zack@codesourcery.com> Cc: Nathanael Nerode <neroden@twcny.rr.com>, <gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org> Subject: Re: other/1634: Request for gcc-cvs-patches list Date: Sat, 11 Jan 2003 21:02:05 +0000 (GMT) On Sat, 11 Jan 2003, Zack Weinberg wrote: > Also so that years later it is easy to get hands on the complete change > committed to CVS as a unit, for backporting or whatever. And for use to rerun changes in case recovery from backups is needed. (Some CVS operations, e.g. tagging, don't have a mechanism by which they can run scripts to send mail etc.. It would be useful if any replacement version control system allowed every write operation to run a script given full information about the operation, so a proper distributed audit trail of changes like this can be created.) -- Joseph S. Myers jsm28@cam.ac.uk
I would love to see this as I have use cvs to revert a patch which causes a problem.
Do we need this any more after svn as svn automatically does patch sets and doing a diff for a patch set ?
Subject: Re: Request for gcc-cvs-patches list On Wed, 28 Dec 2005, pinskia at gcc dot gnu dot org wrote: > Do we need this any more after svn as svn automatically does patch sets and > doing a diff for a patch set ? It's of just as much value for all the audit purposes with SVN as with CVS. The *only* point in this bug's comments which no longer applies is that from comments #2 and #6 (since SVN gives atomic changesets), all other uses still apply.
So almost 7 years later we still have this bug report and nothing has happened -- and the reporter isn't exactly persuing the issue either. Can we just please close this one to avoid bug database polution?
Subject: Re: Request for gcc-cvs-patches list The feature request is just as relevant as it was. Part of the point of a bug database is to track issues over time for as long as they are relevant rather than having them lapse and be forgotten through the passage of time; old but still-relevant issues are not pollution.
The feature request is only worth a bug report if you actually intend to persue the request. Just keeping bug reports open for tracking issues where nothing happens is a Bad Thing. I suggest you bring up your request on gcc@ or on overseers. If no-one but you wants to persue this actively, I'd say there is no reason to keep this report open.
Subject: Re: Request for gcc-cvs-patches list On Mon, 26 Nov 2007, steven at gcc dot gnu dot org wrote: > The feature request is only worth a bug report if you actually intend to persue > the request. Just keeping bug reports open for tracking issues where nothing > happens is a Bad Thing. No, it's a Good Thing; issues where something happens quickly have people actively remembering them and so less need to track them in a tracker, issues with less activity over time have more use for being tracked. We might decide in some cases that a page in projects/ or on the wiki is a better way to track some sorts of feature ideas than the bug database, but simply closing without moving elsewhere would be wrong.
When we moved to git, gcc-cvs has become what this bug has requested. In that it sends the exact patch which was committed to the list now. An example is https://gcc.gnu.org/pipermail/gcc-cvs/2021-September/352936.html