* parse branch and nodeid header lines
* remember the line number where diffs started
Combined, these make mq.patchheader() very useful for parsing and
preserving a patch header through edits. TortoiseHg will use the
nodeid and parent to display these header datums in the graph when
patches are unapplied, and uses diffstartline to parse patch files
using record.parsepatch().
This patch prevents MQ from creating an inconsistent subrepo state. If
the .hgsub file has been changed, and none of the subrepos have
uncommitted changes, creating or updating a patch (using qnew, qrefresh,
or qrecord) will update .hgsubstate accordingly.
If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord
will abort.
Thanks to pmezard for proposing this solution.
If MQ allows modifying .hgsub or .hgsubstate in a patch, it can easily
lead to an inconsistent subrepo state. This patch prevents qrefresh from
adding any modifications to .hgsub or .hgsubstate to a patch. The user
is warned that these files are not included in the patch.
The tests test both the slightly irrational and the pathological cases.
This patch adds an '--exact/-e' option to qpush that will try to push the
patches in the correct location in the DAG. Specifying this option does the
following:
* If --move is specified, abort. It makes no sense to move a patch to the front
of the queue and try to apply it to its parent, because its parent is one of
the patches we just moved it in front of!
* If patches are already applied, abort. We don't want patch changesets
scattered throughout the DAG.
* If local changes are present, abort unless --force is used, as usual.
* Find the first patch we're going to push (if we're pushing multiple patches
with a target or --all).
* If that patch doesn't have a parent, abort, obviously.
* If the parent doesn't exist in the repo, abort. Something is wrong.
* Update to the parent, then continue pushing the patches as normal.
The code eventually converts data through sets to ensure unicity:
do it earlier to allow faster __contains__ lookups and avoid
`del l[l.index(x)]` kind of code.
When using a versioned patch repository, you would get a spurious
warning when deleting and adding the same patch.
Before:
$ hg qdelete --keep 3.diff
$ hg qimport --existing 3.diff
adding 3.diff to series file
3.diff already tracked!
After:
$ hg qdelete --keep 3.diff
$ hg qimport --existing 3.diff
adding 3.diff to series file
Some callers to patchheader.qseries returned the value
further, but pathcheader.qseries does not explicitly
return anything. It was confusing this was returned
further
--force was not necessary when passing --rev since cb494d252290, but this
behaviour is usually harmful when branch names are passed instead of explicit
revisions.
Changeset 1e63d4dee4f6 deprecated qsave and qrestore. In the
deprecating comment, users were referred to 'rebase --mq' which -- at
the time the message was written -- didn't exist. Currently, on the
default branch, rebase *does* take a '--mq' option, but it probably
doesn't do what Dirkjan expected it to do when he wrote the message.
In the original, deprecating commit, little context was provided as to
why this change was made. Based on my recollection, concensus at the
Paris Sprint in February 2010 was that one of the problems with MQ was
that it exposed far too many commands. Notable among these were qsave
& qrestore: very few core developers understood what they did and even
fewer (none, IIRC) actually used them. However, they couldn't be
removed; not only do the usual backwards compatibility reasons apply,
but the hg book refers to them.
