From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: jimb@codesourcery.com (Jim Blandy)
Cc: gdb-patches@sourceware.org
Subject: Re: Managing long patch series
Date: Mon, 29 Oct 2007 18:59:00 -0000 [thread overview]
Message-ID: <200710291838.l9TIc6gc020532@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <m3d4v1d815.fsf@codesourcery.com> from "Jim Blandy" at Oct 26, 2007 11:51:02 AM
Jim Blandy wrote:
> Ulrich, I'm curious what techniques you use to manage these long
> strings of patches. Specifically, I was wondering:
>
> - I'm usually working from a fully-patched tree, and then breaking it
> up into digestible pieces for submission. If you are working this
> way as well, do you have a nice way to ensure the decomposed patch
> series remains equivalent to your fully-patched tree?
>
> - Often I find I need to revise an earlier patch in the series, but
> that chance may affect later patches. Do you have a nice way to
> handle this?
>
> Or is it all just "blood, sweat, and tears"? In the software world,
> that approach usually results in "mistakes", but you and your fellow
> IBM GDB hackers seem to do well.
I'm handling this manually. Usually, I have two trees: one vanilla
check-out at a particular stage, and one "work tree" that started
out as a copy of the vanilla tree with my changes added.
To re-base a patch set to mainline changes, or to some change in an
earlier patch in the series, I'll typically go back to making the
work tree a fresh copy of the vanilla tree, apply the first patch,
resolve any conflicts, re-diff against the vanilla tree to get a
new 'clean' version of the patch, apply the clean patch to the
vanilla tree, then apply the second patch to the work tree and so on.
(After the refresh is complete, I revert the whole series from the
"vanilla" tree again, and verify that "cvs diff" is back to empty.)
I try to break changes out into separate patches earlier rather than
later if possible, but of course on occasion I still break up a big
changeset into multiple smaller ones. To make sure the broken-out
patches still combine back into the original on, I'd typically
compare the work tree after applying the small patch series against
the vanilla tree with the old big patch applied.
> I've tried using quilt, but if one doesn't keep very careful track of
> what's going on things can get very tangled. The Emacs mode helped
> somewhat, but had other flaws, so I set it aside.
I understand that quilt employs a method that is similar to the
manual approach I'm currently using, so if I were to use some tool,
quilt would probably be it. (However, I'm a vi person, so I have no
opinion either way on the Emacs quilt mode ...)
> I've been tempted to try using Mercurial for this.
I've never used that, sorry.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
prev parent reply other threads:[~2007-10-29 18:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-26 18:56 Jim Blandy
2007-10-26 19:26 ` Daniel Jacobowitz
2007-10-29 16:11 ` Jim Blandy
2007-10-27 8:11 ` Vladimir Prus
2007-10-29 15:15 ` Jim Blandy
2007-10-29 18:59 ` Ulrich Weigand [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=200710291838.l9TIc6gc020532@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=jimb@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