From: Doug Evans <dje@google.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] fix PR symtab/15597
Date: Thu, 10 Oct 2013 19:04:00 -0000 [thread overview]
Message-ID: <CADPb22S2nLeN09+=Upgo5h32EvdyHfTiQ38Jams517QktyqpMg@mail.gmail.com> (raw)
In-Reply-To: <87iox5ame5.fsf@fleche.redhat.com>
On Wed, Oct 9, 2013 at 7:29 PM, Tom Tromey <tromey@redhat.com> wrote:
> Doug> So code was moved to a different file and edited in one step
> Doug> (instead of moving it, and then editing it in a separate pass)?
>
> In this case I thought it couldn't reasonably be moved verbatim, since,
> IIRC, prior to my changes it required ELF bits from BFD, not allowed in
> generic code.
Assuming I'm interpreting this correctly,
I think what's allowed can give way to the teeny window in which a
multi-part patch gets checked in.
> Doug> [not that I mind per se, but I thought doing things that way
> Doug> was more than just "nice to have"]
>
> In your case the two changes had nothing to do with one another. I
> think that is a reasonable standard. If you disagree, I'm sure we can
> all agree on some other standard.
My case?
I've long since dropped from cache what that might be referring to so
I had to go looking ...
Are you referring to this?
https://sourceware.org/ml/gdb-patches/2013-09/msg00884.html
I didn't move a function to a new file, the desire to simplify
archeology is what this (sub-)thread is about.
You could be referring to a different patch of course. :-)
No worries. As I say I don't mind. I raise the issue because I was
led to believe archeology simplification (for lack of a better phrase,
blech) is sufficiently important, so I wanted to clear it up.
Perhaps if the amount of code being moved was much larger, or the
changes were much greater, you would have split the patch into two as
a matter of course?
prev parent reply other threads:[~2013-10-10 19:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-08 17:37 Tom Tromey
2013-08-10 5:36 ` Alan Modra
2013-08-12 8:41 ` Tom Tromey
2013-08-12 9:29 ` Alan Modra
2013-08-14 11:25 ` nick clifton
2013-10-08 19:38 ` Tom Tromey
2013-10-08 22:10 ` Hans-Peter Nilsson
2013-10-09 1:27 ` Tom Tromey
2013-10-09 14:09 ` Tom Tromey
2013-10-09 14:54 ` Build regression on 32-bit hosts [Re: [PATCH] fix PR symtab/15597] Jan Kratochvil
2013-10-09 15:46 ` Tom Tromey
2013-10-10 0:17 ` [PATCH] fix PR symtab/15597 Doug Evans
2013-10-10 2:29 ` Tom Tromey
2013-10-10 19:04 ` Doug Evans [this message]
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='CADPb22S2nLeN09+=Upgo5h32EvdyHfTiQ38Jams517QktyqpMg@mail.gmail.com' \
--to=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.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