pwil3058 at bigpond.net.au
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
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
> > 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
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
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 bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
More information about the Mercurial-devel