Bug#298788: [Quilt-dev] [peterc@gelato.unsw.edu.au: Bug#298788: Desirable new feature: quilt merge]
Martin Quinson [EMAIL PROTECTED] wrote: also from the debian BTS. I dunno what to think about it. I never forked any patch, so I've no idea about merging them afterward ;) Assuming that you only try to merge forked patches, a diff3 merge could be performed between the common ancestor of all the files, the old patch and the newly forked one. The common ancestor is easy since you get it in .pc/patch/file, the local file is one of the descendants and 2nd descendant is generated by applying the forked patch to the ancestor. Catalin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298788: [Quilt-dev] [peterc@gelato.unsw.edu.au: Bug#298788: Desirable new feature: quilt merge]
Catalin Marinas [EMAIL PROTECTED] wrote: Martin Quinson [EMAIL PROTECTED] wrote: also from the debian BTS. I dunno what to think about it. I never forked any patch, so I've no idea about merging them afterward ;) Assuming that you only try to merge forked patches, a diff3 merge could be performed between the common ancestor of all the files, the old patch and the newly forked one. The common ancestor is easy since you get it in .pc/patch/file, the local file is one of the descendants and 2nd descendant is generated by applying the forked patch to the ancestor. I just realised this won't work since diff3 will report conflicts for all the changes in both patches, even if they are the same. Maybe xxdiff is a bit smarter here but I'm not sure. The common ancestor should be the state of the tree when the fork happened but if both the old patch and the newly forked one are modified afterwards, this information is no longer preserved. Catalin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298788: [Quilt-dev] [peterc@gelato.unsw.edu.au: Bug#298788: Desirable new feature: quilt merge]
On Thu, 2005-03-10 at 12:42, Martin Quinson wrote: Hello, also from the debian BTS. I dunno what to think about it. I never forked any patch, so I've no idea about merging them afterward ;) Thanks for your time, Mt. PS: as usual, it'd be cool if you could keep both the list and the bug in CC. - Forwarded message from Peter Chubb [EMAIL PROTECTED] - Subject: Bug#298788: Desirable new feature: quilt merge X-Debian-PR-Package: quilt From: Peter Chubb [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Thu, 10 Mar 2005 09:50:48 +1100 X-Mailer: VM 7.17 under 21.4 (patch 17) Jumbo Shrimp XEmacs Lucid Package: quilt Version: 0.39-1 Severity: wishlist Quilt currently has the ability to `fork' a patch, but no simple ability to fold two patches into one. I'd find it useful to be able to merge the top two patches into one. quilt fold doesn't do what I want, as it imports an external patch into an existing patch. Something like f=`quilt files` t=`quilt top` quilt pop for i in $f do quilt add $i done cat patches/$t | quilt fold ed patches/series -! /^$t\/d w q ! is the nearest I've come to what I want... the tricky bit is in the part of the patch before the patch proper. I'd just want to concatenate them, and let the user edit the patch file to fix it up afterwards. Hm... that is indeed a nice idea. Folding is conceptually close, so maybe we can extend `quilt fold' so that it concatenates two patches, and combines comments? I'll think about it. Don't expect to see this in CVS within the next two weeks though (too busy). Cheers, -- Andreas Gruenbacher [EMAIL PROTECTED] SUSE Labs, SUSE LINUX GMBH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
