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

[Peter Williams]

Peter Williams wrote:
> 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.

Doing some research into this I've just realized that mq's qfold command 
has different semantics to quilt's fold command.  This means the the 
fold button gquilt's action bar is invalid when used with an mq back 
end.  I'll have to generate a fix.

FYI quilt's fold command applies a diff supplied as standard input to 
the current working directory (i.e. folds that patch into the top patch) 
whereas mq's qfold command folds a nominated patch (from the series 
file) into the top patch and then deletes it from the series file.

I think that both of these functionalities are useful and it would be 
nice if both commands were modified to allow both functionalities as 
options.

It is tempting to think that hg's patch command could be used to emulate 
quilt's fold command in mq but this is not the case as hg's patch 
command does a commit as part of it's function and I think this would 
have bad consequences for mq.

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

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