gquilt PyGTK GUI wrapper for quilt gets a Mercurial queues (mq) back end

[Peter Williams]

Michael Haggerty wrote:
> Peter Williams wrote:
>> I may be overly cautious but I would have thought it would be best to do
>> such splitting when the patch isn't applied.  Something like:
>>
>> 1. push/pop so that the patch you wish to split is one above the top
>> patch (i.e. the next that will be applied by a qpop).
>> 2. use qnew to create and name a new patch -- this will end up on the
>> queue ahead of the one being split.
>> 3. qpush this new patch
>> 4. apply the parts of the patch being split that you want to be split
>> out and do a qrefresh (this is where a patch editor would come in handy)
>> 5. qpush the old patch -- the parts that have been moved to the new
>> patch should be rejected as already applied
>> 6. qrefresh and it's all over
> 
> Instead of steps 5 and 6 (which rely on the two split patches having no
> conflicts) one could use the following steps, which are guaranteed to
> succeed:
> 
> 5a. Create the second partial patch and push it on the stack:
> 
>     quilt new part2
> 
> 5b. Fold the first partial patch, in reverse, into part2:
> 
>     interdiff -p1 patches/part1 /dev/null | quilt fold
> 
> This uses "interdiff", from patchutils.
>  The text after this step is the
> same as before patch part1 was applied, even though part1 is still on
> the stack.  However, "quilt fold" ensures that the correct files have
> been added to part2.
> 
> 5c. Apply the original, full patch in full:
> 
>     quilt fold <patches/fullpatch

It would be better if 5b and 5c could be done without having to use the 
path name of the patch files e.g. if quilt fold had an option that would 
allow a patch from the series to be folded into the top patch by just 
using its name

> 
> This step cannot have any conflicts as long as fullpatch originally
> applied without conflicts.
> 
> 5d. Refresh part2.
> 
> 5e. Delete the original fullpatch.  Applying part1 followed by part2 is
> now identical to the original fullpatch.

Much neater.  As I see it it boils down to three steps:

1. Clone a patch (automatable)
2. Decide what parts you want to keep and make those modifications to 
the cloned patch (NOT automatable)
3. Create a new patch which contains the bits removed from the clone and 
delete the original patch (or remove the patch bits in the clone from 
the original patch) (automatable).

So we need to provide 2 new functions in order to facilitate patch 
splitting.  From the POV of gquilt, it would be preferable if these new 
functions were implemented in quilt and mq and gquilt could just call 
them.  However, I'll see if I can come up with an interim solution using 
existing commands and (perhaps) patchutils commands.

> 
> It sure would be nice to have other utilities for tidying up patches
> before commit.  For example:
> 
> - swapping the order of two patches.  This can be done automatically if
> the patches don't conflict, but requires hand-fixing otherwise.

This is one I'm not eager to do without the necessary functionality 
being provided in quilt and/or mq as it would involve me.  Possibly 
promote/demote commands would do the trick.

> 
> - combining two adjacent patches into a single one

This can probably be implemented using existing commands so I'll try to 
add the functionality to gquilt using them.  Probably only allowing the 
next patch on the stack to be merged with the top patch, though.

Peter
-- 
Peter Williams                                   pwil3058 at bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce