This is the mail archive of the
mailing list for the GCC project.
Let's remove all (or the largest) diffs from gcc-cvs@
- From: Hans-Peter Nilsson <hp at axis dot com>
- To: <gcc at gcc dot gnu dot org>
- Date: Sat, 18 Jan 2020 15:30:50 +0100
- Subject: Let's remove all (or the largest) diffs from gcc-cvs@
- Ironport-sdr: Fo/GjNSg8zMori6D9DsSrdj9cflClDrvOTwjPFUwHBppjDtxCxao2dXQj2jgLeaGga/mYg1F28 kFC0IyZKZ2ZgB7os7YesdnCjY4WhOeremcUhwsHgmVbas/03Z018ozEklCxF5eEb12VugUe5Rn Q9uyPLVyq9QClM+8uIRFTAstvjaN+rVSw3UmsFEZoP0jCuULdQdy6WjrOp8LPbyxfGCKm03ZHm vu2DXgNxYScLqpczcRZkGlPsgXMlGjgrhfCqUD+P1SZEXGzBz81shW+W7IDrMjgcS4PSnd2Efe JxY=
TL;DR: See subject. Verbosity follows.
The git transition is mostly for the better. Thanks to those
investing time and effort. There's always fallout. Here's one
In the distant past with svn, there messages to gcc-cvs@ were
somewhat like git show --stat, i.e. without the actual changes:
Date: Wed Dec 25 00:16:22 2019
New Revision: 279730
Now after the git transition, patches *always* come with a diff, as below.
Author: GCC Administrator <email@example.com>
Date: Wed Jan 15 00:16:26 2020 +0000
gcc/DATESTAMP | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/DATESTAMP b/gcc/DATESTAMP
index 3a0695d..ba948c5 100644
@@ -1 +1 @@
(No, not just the daily bump, I just wanted to avoid a person
being pointed out and had no commits myself "within reach".)
Why the diff? I don't remember the absence of a diff being a
problem in the svn era (or at least wasn't argued much on the
Compare also to traffic on binutils-cvs@ and gdb-cvs@, where
there *are* diffs posted, but apparently there's a size limit; I
see "[diff truncated at 100000 bytes]" for a post on gdb-cvs.
Still, I very much prefer no diff at all.
Does someone actually (not theoretically) have a need that is
fulfilled by those diffs?
Can we remove them altogether?
If not, can we cap the messages at a size limit?
Note: I'm aware of the discussion regarding limiting posts for
certain branches to gcc-cvs; that's incidental. Note also that
my own needs are handled by means of procmail, I was just
bothered enough to bring it up, and less email traffic on
sourceware means more bandwidth for actual commit traffic. :)