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

[Peter Williams]

Peter Williams wrote:
> Steve Borho wrote:
>> On Tuesday 06 February 2007 06:04:58 am Rafael Villar Burke wrote:
>>> Peter Williams wrote:
>>>> I have just released version 0.18 of my gquilt
>>>> <http://users.bigpond.net.au/Peter-Williams/> program via a freshmeat
>>>> update.  The major new feature of this release is the ability to use
>>>> the mq extension to Mercurial as a back end in lieu of quilt (if
>>>> desired).
>>> Great!. I've updated the description for it on pygtk.org so the new
>>> Mercurial queues support is reflected.
>>>
>>> As a feature request, would you consider adding the possibility of being
>>> able to split a patch in a series of patches, be it using hunks or,
>>> better, by selecting some lines that would be removed from the current
>>> patch and would be splitted into a new patch in the series. That way you
>>> could easily get fine grained patches without worrying for having about
>>> it all the time while editing. Maybe rediff in patchutils can help with
>>> that.
>>
>> You can do a fair amount of this with Qct. 
>> If you remove a particular file from a patch (refreshing the patch 
>> without it), then all of it's changes are left in your working 
>> directory.  From there you can use the 'change selection' feature to 
>> pick the changes in the file you want in this patch (you can do this 
>> simultaneously to all files in the patch).  Once you get the list of 
>> changes pruned down to just the first patch, you refresh the patch, 
>> exit Qct and run 'hg qnew -f newpatch.txt', start Qct again and repeat.
>>
>> This process is currently clunky; it would be nice if Qct automated 
>> the 'new patch' process for you.  Plus, mq does not allow you to 
>> refresh a patch with zero files in it (the command line structure of 
>> qrefresh doesn't allow it), so there has to always be at least one 
>> file left in the patch during this process.
>>
>> Just thought I would throw that out there.
>>
> 
> 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
> 
> Peter
> PS One way of doing step 4 above would be to use "hg patch 
> .hg/patches/oldpatchname" and then revert the bits you don't want 
> included in the new patch.

This would be easier if the extdiff extension allowed the external diff 
viewer to modify files in the working directory.  That way tools such as 
meld could be used to back out the bits that you don't want in the new 
patch.

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

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