The --amend flag can be used to amend the parent of the working directory
with a new commit that contains the changes in the parent in addition to
those currently reported by "hg status", if there are any. The old commit
is stored in a backup bundle in ".hg/strip-backup"(see "hg help bundle"
and "hg help unbundle" on how to restore it).
Message, user and date are taken from the amended commit unless specified.
When a message isn't specified on the command line, the editor will open
with the message of the amended commit.
It is not possible to amend public changesets (see "hg help phases") or
changesets that have children.
Behind the scenes, first commit the update (if there is one) as a regular
child of the current parent. Then create a new commit on the parent's
parent with the updated contents. Then change the working copy parent
to this new combined changeset. Finally, strip the amended commit and
update commit created in the beginning.
An alternative (cleaner?) approach of doing this is suggested here:
http://selenic.com/pipermail/mercurial-devel/2012-March/038540.html
It is currently not possible to amend merge commits or recursively,
this can be added at a later time.
splitblock() was added to handle blocks returned by bdiff.blocks() which differ
only by blank lines but are not made only of blank lines. I do not know exactly
how it could happen but mdiff.blocks() threshold behaviour makes me think it
can if those blocks are made of very popular lines mixed with popular blank
lines. If it is proven to be wrong, the function can be dropped.
The first implementation made annotate share diff configuration entries. But it
looks like users will user -w/b for annotate but not for diff, on both the
command line and hgweb. Since the latter cannot use command line entries, we
introduce a new [annotate] section duplicating the diff whitespace options.
This changeset flips the default value of ui.commitsubrepos setting
from True to False and adds a --subrepos flag to commit.
The commit, status, and diff commands behave like this with regard to
recusion and the ui.commitsubrepos setting:
| recurses | recurses
| by default | with --subrepos
--------+---------------+----------------
commit: | commitsubrepo | True
status: | False | True
diff: | False | True
By changing the default from True to False, the table becomes
consistent in the two columns:
* without --subrepos on the command line, commit will abort if a
subrepo is dirty and status/diff wont show changes inside subrepos.
* with --subrepos, all three commands will recurse.
A --subrepos flag on the command line overrides the config settin.g
You can get into trouble if you commit, update back to an older
changeset, and then rollback. The update removes your valuable changes
from the working dir, then rollback removes them history. Oops: you've
just irretrievably lost data running nothing but core Mercurial
commands. (More subtly: rollback from a shared clone that was already
at an older changeset -- no update required, just rollback from the
wrong directory.)
The fix assumes that only "commit" transactions have irreplaceable
data, and allows rolling back non-commit transactions as always. But
when rolling back a commit, check that the working dir is checked out
to tip, i.e. the changeset we're about to destroy. If not, abort. You
can get back the old (dangerous) behaviour with --force.
This feature is more a way to test patching without a working directory than
something people asked about. Adding a --rev option to specify the parent patch
revision would make it a little more useful.
What this change introduces is patch.repobackend class which let patches be
applied against repository revisions. The caller must supply a filestore object
to receive patched content, which can be turned into a memctx with
patch.makememctx() helper.
These open the changelog and manifest, respectively, directly so you don't
need to specify the path.
The options have been added to debugindex, debugdata and debugrevlog.
The patch also fixes some minor usage-related bugs.
Adds a new discovery method based on repeatedly sampling the still
undecided subset of the local node graph to determine the set of nodes
common to both the client and the server.
For small differences between client and server, it uses about the same
or slightly fewer roundtrips than the old tree-based discovery. For
larger differences, it typically reduces the number of roundtrips
drastically (from 150 to 4, for instance).
The old discovery code now lives in treediscovery.py, the new code is
in setdiscovery.py.
Still missing is a hook for extensions to contribute nodes to the
initial sample. For instance, Augie's remotebranches could contribute
the last known state of the server's heads.
Credits for the actual sampler and computing common heads instead of
bases go to Benoit Boissinot.
This drops the options to run arbitrary shell commands within
commits and the option to create a file that gets appended to
in every revision. It now supports to not write file data at
all, which is very fast for generating a pure 00changelog.i
(useful for discovery tests, for instance).
Timings for 1000 linear nodes:
* Old `hg debugbuilddag -o '+1000'` took 4.5 secs.
* New `hg debugbuilddag -o '+1000'` takes 2 secs.
* New `hg debugbuilddag '+1000'` takes 0.8 secs.
(The last one creates only 00changelog.i).
getbundle(common, heads) -> bundle
Returns the changegroup for all ancestors of heads which are not ancestors of common. For both
sets, the heads are included in the set.
Intended to eventually supercede changegroupsubset and changegroup. Uses heads of common region
to exclude unwanted changesets instead of bases of desired region, which is more useful and
easier to implement.
Designed to be extensible with new optional arguments (which will have to be guarded by
corresponding capabilities).
known([Node]) -> [1/0]
Returns 1/0 for each node, indicating whether it's known by the server.
Needed for new discovery protocols introduced in later patches.
When bisect ends in a merge point, and one of the parent wasn't checked,
this usually means the culprit is in a branch that wasn't scanned.
For this case we provide a new command which extends the range of the bisect
search to the common ancestor of the parents of the merge.
Since bookmarks are no longer merged with repo.tags() as of
8e2d23f4bd25, they don't show up in `hg id` as they used to. This adds
them back into the summary that `hg id` prints, and adds a
-B/--bookmarks flag alongside the -t/--tags and -b/--branch options.
Note this introduces a slight backwards-incompatibility: the summary
printed by `hg id` now separates bookmarks from tags with a space, as
seen below, instead of running it into the tags list.
Default summary output:
$ hg id
db815d6d32e6 tip/tag1 bm1/bm2
Output with --bookmarks:
$ hg id --bookmarks
bm1 bm2
See also 5672c9e8202d which adds bookmarks back into `hg summary`.
For GUI clients its sometimes important to know which files will be ignored and
which files will be important. This allows the GUI client to skipping redoing a
'hg status' when the files are ignored but have changed. (For instance, a
typical case is that the "build" directory inside some project is ignored but
files in it frequently change.)
If --insecure specified, it behaves in the same way as no web.cacerts
configured.
Also shows hint for --insecure option when _verifycert() failed. But currently
the hint isn't displayed on SSLError, because it needs a certain level of
changes.
As with push, the optional destination path is ignored for the
subrepositories, i.e., they are always compared with their default
push path. Fixing this is Issue1852.
