MQ usability

Peter Williams pwil3058 at
Sun Aug 23 20:45:11 CDT 2009

On 24/08/09 09:59, Peter Williams wrote:
> On 24/08/09 01:51, Patrick Mézard wrote:
>> Peter Williams a écrit :
>>>> Could you elaborate on how you use qsave exactly?
>>>> Are you talking about rebasing patches with the complicated
>>>> qsave/qpush -m dance?
>>> I also suggested that a special version of rebase (e.g. qrebase) could
>>> be used to replace qsave (which would also make qrestore unnecessary).
>>> Its interface could be considerably simpler than rebase's because less
>>> things would need to be specified.
>> What do you have in mind?
> My main thought was that the source options (i.e. --source/--base) would
> not need to be specified for qrebase as you already know what has to be
> moved.

Also --keepbranch and --collapse seem to be surplus to requirements.

Additionally, the command can check that all patches are applied and 
abort if they aren't and -f/--force isn't specified.

>> I you rebase your queue systematically (I am not promoting this, but
>   >  otherwise you already do enough revision manipulations that finding the
>   >  target head has a marginal cost) instead of qpop/qpushing, the only
> argument
>   >  to pass is usually the target head revision. Perhaps, we could add
> even more
>   >  smarts and have an argument to rebase onto the "tipmost" revision on
> current branch,
>   >  excluding revisions being rebased, but that would go in rebase extension.
> Yes, default destinations (similar to those for 'update') would be good
> (and I must admit that I assumed that they were already in place).
> I think that qrebase could be just a thin wrapper around rebase that
> automatically supplies the source options but for it to be properly
> integrated into MQ rather than just an alias in the configuration file(s).

Having thought about this some more (while working on a patch), I think 
that 'qreparent' would be a better name for an mq specific version of 
'rebase' as it fits in better with mq's terminology (e.g. the semantics 
of the 'qparent' and 'qbase' tags).

 > As I understand it there's a mechanism whereby an extension can declare
 > a dependence on another extension and that it will be loaded if the
 > dependent extension is loaded?  So mq could declare a dependence on
 > rebase and then implement qrebase on top of rebase.  How does that
 > sound?

It seems I was mistaken here as this mechanism isn't powerful enough 
(but having ui as an optional argument to extsetup() would make it so). 
  So a direct import of rebase into mq will be required in the meanwhile.

 >  I can work on a patch if you like?

I'm working on this and here's a help message for the proposed command:

hg qreparent [-d REV] [--keep] | [-c] | [-a]

move all applied patches to a different location

     qreparent uses repeated merging to graft a patch series from one 
part of
     history onto another. This can be useful for updating the patches when
     the master development tree is updated.

     If a qreparent is interrupted to manually resolve a merge, it can be
     continued with --continue/-c or aborted with --abort/-a.

     If all patches are not applied, qreparent will abort unless the
     -f/--force option is specified.


  -d --dest      reparent onto the given revision
  -f --force     reparent partially applied series
     --keep      keep original revisions
  -c --continue  continue an interrupted reparenting
  -a --abort     abort an interrupted rebase
     --style     display using template map file
     --template  display with template

use "hg -v help qreparent" to show global options

Peter Williams                                   pwil3058 at

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

More information about the Mercurial-devel mailing list