Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Nick Roberts <nickrob@snap.net.nz>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org, Daniel Jacobowitz <drow@false.org>
Subject: Re: [PATCH] Another annotation for threads
Date: Fri, 06 Jun 2008 03:00:00 -0000	[thread overview]
Message-ID: <18504.43037.355720.133165@kahikatea.snap.net.nz> (raw)
In-Reply-To: <200806060338.51693.pedro@codesourcery.com>

 > 2008-05-21  Nick Roberts  <nickrob@snap.net.nz>
 > 
 >         * annotate.c (annotate_thread_changed): New function.
 >         * thread.c (thread_command) : Use it.
 >         * infrun.c (normal_stop): Use it.
 > 
 > This broke the build, as the annotate_thread_changed function isn't
 > declared anywhere.
 > 
 > I checked the attached in, as obvious.

Yes, sorry.  I have several changes in that directory and I missed that file in
the patch that I posted.

 > Out of curiosity, was there a reason you committed every file as
 > individual commits?  It's customary to do a patch per commit
 > (not that is matter that much with CVS, but still nice to be
 > able to correlate by date, and to look at gdb-cvs).

It's the way VC works in Emacs.  I could use pcl-cvs but I've not really got
used to it.  Each file is committed individually but the changeset is given
in the ChangeLog, although multiple ChangeLogs are needed across directories
as is the case here.

It would be nice to move GDB to a modern version control system where patches
are really committed as changesets.  Systems such as GIT allow local branches
also which would help to keep local changes separate too.

It's also easier to try multiple file patches out from the mailing list and
revert them, etc, etc.

For now, anyway, I'll try to use pcl-cvs to keep the traffic down on gdb-cvs.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


  reply	other threads:[~2008-06-06  3:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-21  6:13 Nick Roberts
2008-05-21  8:54 ` Eli Zaretskii
2008-06-05 19:30 ` Daniel Jacobowitz
2008-06-05 21:20   ` Nick Roberts
2008-06-05 21:26     ` Daniel Jacobowitz
2008-06-05 22:02       ` Joel Brobecker
2008-06-06  1:03         ` Nick Roberts
2008-06-06  6:59           ` Joel Brobecker
2008-06-06  0:50       ` Nick Roberts
2008-06-06  1:06         ` Tom Tromey
2008-06-06  2:30           ` Daniel Jacobowitz
2008-06-06  2:44             ` Tom Tromey
2008-06-06  2:39         ` Pedro Alves
2008-06-06  3:00           ` Nick Roberts [this message]
2008-06-06 11:44             ` Daniel Jacobowitz

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=18504.43037.355720.133165@kahikatea.snap.net.nz \
    --to=nickrob@snap.net.nz \
    --cc=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@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