Re: How to cope with patches sanely
On Sun February 3 2008 10:47:59 am Raphael Hertzog wrote:
> On Sat, 02 Feb 2008, Kumar Appaiah wrote:
> I was explaining how I would handle patches on top of upstream code. And
> where you have to update the patches when the upstream code changes.
> Rebase is exactly the process of "updating patches" while merge is really
> "keep the old patch and add fixups patch to reconcile after conflicts".
From what I remember of looking at rebase when I was evaluating git, isn't a
side effect of it that it causes inconvenience for everyone that tracks your
tree? That is, if you are going to use rebase on a tree, it is generally a
private tree used on only one of your own machines, rather than something
that others pull from as well?
I have yet to see a convenient way to manage this, with any VCS whatsoever,
that:
1. Lets you easily check out the state of the patched tree as of any given
point in time
2. Lets you easily maintain a patchset where the patches on any given version
are clearly separated into logical patches that can easily be sent to
upstream
3. Facilitates teamwork with others using your repo
The closest that I've seen yet is Mercurial's mq extension, which is
quilt-like, in the mode where both the main repo and the mq area are
versioned. This fails #1 because you have to get the main repo and the mq
area to the same point manually, but succeeds on the others.
I also am meaning to toy around with Mercurial's transplant extension, which
can be similar to git's rebase (I gather), but with some other
tree-manipulating features. But that fails the "easily" part because it's
fairly esoteric VCS stuff.
Frankly I have been able to keep my deltas to upstream small enough that just
using a basic Mercurial repo for this has been fine. Although I maintain a
fairly large package (Bacula), it is still nowhere near the size of KDE and
X, and I also have the benefit of a very good working relationship with
upstream.
-- John
Reply to: