From: Eli Zaretskii <eliz@gnu.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: vladimir@codesourcery.com, chgenly@gmail.com,
gdb-patches@sources.redhat.com
Subject: Re: gdb.texinfo patch for -var-list-children (2)
Date: Mon, 22 Jun 2009 04:42:00 -0000 [thread overview]
Message-ID: <E1MIbMV-0000AD-Bu@fencepost.gnu.org> (raw)
In-Reply-To: <20090622031832.GA7766@adacore.com> (message from Joel Brobecker on Sun, 21 Jun 2009 20:18:32 -0700)
> Date: Sun, 21 Jun 2009 20:18:32 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Vladimir Prus <vladimir@codesourcery.com>, Chris Genly <chgenly@gmail.com>, gdb-patches@sources.redhat.com
>
> > > I suggest you use unified diffs for patches (cvs diff -u). The
> > > default "context" format is some historically-inflicted thing that
> > > is hard to read.
> >
> > I'm fine with both context and unified diffs.
>
> That's very kind of you to accept context diffs, but I do feel that
> most reviewers are more comfortable with unified diffs - so I suggest
> we keep asking for unified for future patches. I, for one, cannot
> read context diffs. I usually don't ask a resend, and convert the patch
> from one format to the next, but I like to ask that future patches
> be in unified format.
I'm surprised by such strong feelings, since the difference between
context and unified diffs is not so large.
Anyway, all GNU projects I ever contributed to accept both context and
unified diffs, and in fact so does GDB, because gdb/CONTRIBUTE says
this:
o Submitting Patches
[...]
The patch itself. If you are accessing the CVS repository use
"cvs update; cvs diff -cp"; else, use "diff -cp OLD NEW" or
"diff -up OLD NEW". If your version of diff does not support
these options, then get the latest version of GNU diff.
So if from now on we are going to request only unified diffs, we
should at least change this text. FWIW, I don't think we should
change this policy because it may prove inconvenient in some
situations (e.g., the Patch utility produces reject files in context
diff format). But that's me.
next prev parent reply other threads:[~2009-06-22 4:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-20 4:11 Chris Genly
2009-06-20 8:45 ` Vladimir Prus
2009-06-20 10:01 ` Eli Zaretskii
2009-06-22 3:18 ` Joel Brobecker
2009-06-22 4:42 ` Eli Zaretskii [this message]
2009-06-22 15:02 ` Daniel Jacobowitz
2009-06-23 1:00 ` Eli Zaretskii
2009-06-23 3:19 ` Daniel Jacobowitz
2009-06-20 15:18 ` Eli Zaretskii
2009-06-20 20:31 ` Chris Genly
2009-06-20 21:33 ` Chris Genly
2009-07-04 12:13 ` Eli Zaretskii
2009-06-20 23:12 ` Eli Zaretskii
2009-06-20 23:17 ` Samuel Bronson
2009-06-21 19:28 ` Chris Genly
2009-06-21 23:12 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1MIbMV-0000AD-Bu@fencepost.gnu.org \
--to=eliz@gnu.org \
--cc=brobecker@adacore.com \
--cc=chgenly@gmail.com \
--cc=gdb-patches@sources.redhat.com \
--cc=vladimir@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox