The old docs emphasized topological heads rather than branch heads and
incorrectly defined branch heads as not having children rather than
descendants.
At the moment, creating secret commits is slightly cumbersome. They
can either be created by changing the default commit phase to secret
or by doing `hg phase --secret --force`. Both of these make secret
commits appear to be like some kind of advanced feature.
Secret commits, however, should be a convenient feature for people who
want to work on a private branch without affecting anyone else. There
should therefore be a prominent and convenient method for creating
secret commits.
Since the default phase is draft and there is no need to use --force
to go from a secret phase to any other phase, this patch
intentionally does not add --draft and --public options.
The --force option in merge does not make what people think it does so
it may not be visible to everyone.
I have local changes and want to pull one's changes which made 2 heads.
The --force option in help says
-f --force force a merge with outstanding changes
so I can expect that I can use it to force the merge and commit it in my
local repository without taking my local changes into account. But
merging with -f keeps local changes and "add" them: they must be
committed or reverted before doing the merge commit. The merge -f cannot
be reverted so it leads my repository in a bad state: cannot commit
merge and don't want to revert/commit local changes yet.
Message in help have been updated to emphasize the fact that local
changes are included in the merge.
Changes the parents command to use filectx to look up the change node
instead of doing it manually. This allows extensions to modify the
file-to-commit relationship behind the filectx api.
RST's role syntax means something different sometimes when it's in
some places that are poorly documented and vary betwen minirst and
docutils. Line wrapping will thus sometimes break everything.
Markup for links to mercurial commands is appearing in the help
documentation.
This patch fixes the markup so mercurial command reference links are
correctly generated in the help documentation.
Because dirstate._branch() strips leading/trailing spaces from .hg/branch,
"hg branch ' foo '" should abort if branch "foo" exists in another head.
tag command had a similar bug and fixed by 11d102903884.
You can't close a branch that hasn't got a head.
newbranch + commit --close-branch must fail
newbranch + commit + commit --amend --close-branch must fail
You must not be allowed to close a branch that is not defined.
This patch resolves a single divergent bookmark if a divergent bookmark exists
in the target revision and it current bookmark is not an ancestor of the target
revision, else it would already be handled by the previous patch in this
series.
Test coverage is added.
This patch is a follow-up to 00b2764d68e4 that resolves divergent bookmarks
between the to-be-forwarded bookmark MARK and the new descendant. This
situation can happen when pulling new changesets, updating to the divergent
bookmark, abandoning the previous changesets with strip, and then moving MARK
to MARK@N.
Test coverage is added.
This change allows setting or deleting multiple bookmarks at once. If more than
one is being set and --inactive is not given, the first one is made active.
Before this patch, "commonincoming" calculated by
"discovery.findcommonincoming()" is cleared, only if "default" URL
without branch part (tail "#branch" of URL) differs from
"default-push" URL without branch part.
But common revisions in "commonincoming" calculated for a branch
doesn't include ones for another branch, even if URLs without branch
part are same. The result of "discovery.findcommonoutgoing()"
invocation with such "commonincoming" becomes incorrect in some cases.
This patch clears "commonincoming", also if branch part of "default"
differs from one of "default-push".
To avoid redundant looking up:
- "ui.expandpath('default')" and "ui.expandpath('default-push',
'default')" are not compared directly, even though they contain
branch information, because they are not yet normalized by
"hg.parseurl()": tail "/" of path, for example
- "commonincoming" is not cleared, if branch isn't specified in
"default" URL, because such "commonincoming" contains common
revisions for all branches
This patch also tests "different path, same branch" pattern to check
careless degrading around comparison between source and destination.
Before this patch, "incoming" information of "hg summary --remote" is
not sensitive to the branch specified in the URL of the destination
repository, even though "hg pull"/"hg incoming" are so.
Invocation of "discovery.findcommonincoming()" without "heads"
argument treats revisions on branches other than the one specified in
the URL as incoming ones unexpectedly.
This patch looks head revisions, which are already detected by
"hg.addbranchrevs()" from URL, up against "other" repository, and
invokes "discovery.findcommonincoming()" with list of them as "heads"
to limit calculation of incoming revisions.
Before this patch, "outgoing" information of "hg summary --remote" is
not sensitive to the branch specified in the URL of the destination
repository, even though "hg push"/"hg outgoing" are so:
Invocation of "discovery.findcommonoutgoing()" without "onlyheads"
argument treats revisions on branches other than the one specified in
the URL as outgoing ones unexpectedly.
This patch looks head revisions, which are already detected by
"hg.addbranchrevs()" from URL, up against local repository, and
invokes "discovery.findcommonoutgoing()" with list of them as
"onlyheads" to limit calculation of outgoing revisions.
-r has a default value of '' in the command line. The function default value of
'tip' is thus never used and any attempt at specifying revisions without -r
will fail.
It seems like then intended behavior was that 'hg debugrebuildstate' without
any parameters should set the parents to tip. That would be very confusing now
when the command primarily is used to recover from incorrect stat info.
It is apparently undocumented that '' is the same as '.' ... unless it is
passed in a place where revsets are used.
A common usecase for export is to preview the patch that will be patchbombed or
to see what changed in a revision found by bisect. Showing the working
directory parent is thus a useful and obvious default.
Backout 308a153b9120. The changeset prevented closing non-head changesets but
did not provide any rationale or test case and I don't see what value it adds.
Users might have their reasons to commit something anywhere - and close it
immediately.
And contrary to the comment that is removed: The topo heads set is _not_
included in the branch heads set of the current branch. It do not include
closed topological heads.
The change thus prevented closing commits on top of closing commits. A valid
usecase for that is to merge closed heads to reduce the number of topological
heads.
The only existing test coverage for this is the failing double close in
test-revset.t. It was added in dc0e42c06b4e and seems to not be intentional.
When the revisions to graft are numerically close to the destination, this
avoids two walks up the DAG, which for a repository with over 470,000
changesets translates to around 2.2 seconds.
When the revisions to graft are numerically close to the destination, this
avoids one walk up the DAG, which for a repository with over 470,000
changesets translates to around 1.1 seconds.
Consider a bookmark B that exists both locally and remotely. If B is updated
remotely, and then a pull is performed where the pull set contains the new
location of B, the bookmark is updated locally. However, if remote B is
updated in the middle of a pull to a location not in the pull set, the
bookmark won't be updated locally at all.
To fix this, list bookmarks before pulling in changesets, not after. This
still leaves a race open if B gets moved in between listing bookmarks and
pulling in changesets, but the race window is much smaller. Fixing the race
properly would require a bundle format upgrade.
test-hook.t's output changes because we no longer do two listkeys calls during
pull, just one.
test-pull-http.t's output changes because we now search for bookmarks before
searching for changes.
Before this patch, "hg bundle --branch foo other" fails to create
bundle file, if specified "foo" branch is created newly on the local
repository.
"hg bundle" uses "hg.addbranchrevs(repo, other, ...)" to look branch
names up, even though other outgoing-like implementation uses
"hg.addbranchrevs(repo, repo, ...)". In the former invocation, "other"
repository recognizes such branches as unknown, so execution is
aborted.
This patch uses "hg.addbranchrevs(repo, repo, ..)" in "hg bundle" to
bundle revisions on such branches correctly.
If the active bookmark doesn't point at a parent of the working dir
(e.g. a pull moved it out from under us), we nonetheless show it as
active. This follows on 13ea5e437ff8 in removing the dichotomy (at least
in the UI) between "current" and "active" bookmarks.
If the current bookmark (the one listed in .hg/bookmarks.current)
doesn't point to a parent of the working directory, e.g. if it was moved
by a pull, use that as the update target instead of the tipmost
descendent.
A small predicate is (finally) added to the bookmarks module to check
whether the current bookmark is also active.
We can not use `len(repo,changelog)`, it may be a filtered revision. We now use
`repo,changelog.tip()` to fetch this information.
The `tip` command is also fixed and tested
Thanks goes to Idan Kamara for the initial report.
Suppose we want to perform a single-level completion (i.e. without
--full) of "fi" in a repo containing "fee", "fie/dead", "fie/live",
and "foe".
If we give back "fie/" as the only answer, the shell will consider
the completion to be unambiguous, and will append a space after the
completion. We can't complete "fie/live" or "fie/dead" without
first backspacing over that space.
We used to thus create two fake names, "fie/a" and "fie/b", to force
the shell to consider the completion to be ambiguous. It would then
stop at "fie/" without appending a space, allowing us to hit tab
again to complete "fie/live" or "fie/dead".
The change here arises from realising that we only need to force
the shell to consider a completion as ambiguous if we have exactly
one directory and zero files as possible completions.
This prevents spurious names from showing up as possible completions
when they don't need to be invented in the first place.
The bash_completion code uses "hg status" to generate a list of
possible completions for commands that operate on files in the
working directory. In a large working directory, this can result
in a single tab-completion being very slow (several seconds) as a
result of checking the status of every file, even when there is no
need to check status or no possible matches.
The new debugpathcomplete command gains performance in a few simple
ways:
* Allow completion to operate on just a single directory. When used
to complete the right commands, this considerably reduces the
number of completions returned, at no loss in functionality.
* Never check the status of files. For completions that really must
know if a file is modified, it is faster to use status:
hg status -nm 'glob:myprefix**'
Performance:
Here are the commands used by bash_completion to complete, run in
the root of the mozilla-central working dir (~77,000 files) and
another repo (~165,000 files):
All "normal state" files (used by e.g. remove, revert):
mozilla other
status -nmcd 'glob:**' 1.77 4.10 sec
debugpathcomplete -f -n 0.53 1.26
debugpathcomplete -n 0.17 0.41
("-f" means "complete full paths", rather than the current directory)
Tracked files matching "a":
mozilla other
status -nmcd 'glob:a**' 0.26 0.47
debugpathcomplete -f -n a 0.10 0.24
debugpathcomplete -n a 0.10 0.22
We should be able to further improve completion performance once
the critbit work lands. Right now, our performance is limited by
the need to iterate over all keys in the dirstate.
When completing a "label" (a symbolic name for a commit), the
bash_completion script currently has to invoke hg three times. For
a large repository, the cost of starting up and loading all the
necessary context over and over is very high.
For instance, in mozilla-central:
time (export HGPLAIN=1; hg tags -q; hg bookmarks -q; hg branches) >/dev/null
0.446 sec
Compare with the debuglabelcomplete command that this commit adds:
time hg debuglabelcomplete >/dev/null
0.148 sec
This greatly helps responsiveness.
After this change, moving the active bookmark somewhere other than the
current changeset (i.e., with --rev) deactivates it. Previously it would
remain in .hg/bookmarks.current, which seems like a bug.
Allow a bookmark that points to the current changeset to be made the
active bookmark without requiring --force. Previously, this would've
aborted with:
abort: bookmark 'Z' already exists (use -f to force)
Allow 'hg bookmark MARK', with an existing bookmark MARK, to move the
bookmark forward to the current or specified revision, if the target
revision is a descendant of the revision the bookmark currently points
to. Prints a status message including the revision the bookmark was
formerly at:
$ hg bookmark Z
moving bookmark 'Z' forward from 663762316562
Test coverage is added.
Since re2 is enormously faster than Python's re module, this should
help performance, ceteris paribus. grep currently has other huge
performance problems that mask any gain :-(
We move the logic for generating the unformatted ReST source to the
help module, in order to eventually avoid calling commands.help_()
from hgweb.
No functionality change.
We create a new function commitstatus() in cmdutil that handles printing
the status message(s) after a commit. This will allow other commit-like
commands to use it, and in particular is step 2 towards removing
backout's call to commands.commit.
This is step 1 to remove backout's call to commands.commit. We don't use
the options again anywhere below except for backout's own purposes,
specifically choosing a merge tool, so we just write the commit options
in directly.
There's no way for addremove to show up in backout's opts dictionary. It
was being set manually because cmdutil.commit expected it to be there
(and would throw an exception if it wasn't). This was fixed waaaaaaay
back in:
changeset: 5829:e05e83ad9d2b
user: Kirill Smelkov <kirr@mns.spb.ru>
date: Thu Jan 10 12:07:18 2008 +0300
summary: cmdutil.commit: extract 'addremove' from opts carefully
Before this change, backout would explicitly set the options it passed
to commands.revert in order to fall thru most of its logic and call
cmdutil.revert. This change makes it clearer what backup is trying to
accomplish and makes it robust against changes to the revert command.
The checkexact() helper function was calling repo.rollback() from inside
an open transaction. In addition to being insane, this is unnecessary
because import will release the transaction on an exception.
It turns out that this has been broken since the feature was first
introduced, first released in v1.0:
changeset: 4263:3e8ce73e04cd
user: Brendan Cully <brendan@kublai.com>
date: Thu Mar 22 10:44:59 2007 -0700
files: mercurial/commands.py mercurial/patch.py
description:
Add import --exact.
When this option is set, import will apply the patch (which must
be generated by export) to the parents specified in the patch,
and check that the node produced by the patch matches the node
ID in the patch.
Before this change, 'hg summary' would not show the active bookmark
unless it pointed to the working directory parent. After this change, it
will show it in parentheses, like so:
parent: 18581:f0ff45fe6700 tip
summary: simplify handling of active bookmark
branch: default
bookmarks: [crew]
commit: (clean)
update: (current)
The dispatch code now enables filtering of "hidden" changesets globally. The
filter is installed before command and extension invocation. The `--hidden`
switch is now global and disables this filtering for any command.
Code in log dedicated to changeset exclusion is removed as this global filtering
has the same effect.
The phase command have some logic to report change made. We ensure this logic
run unfiltered.
With --force the command can change phase of a changeset for public to draft.
Such change can lead to obsolescence marker to apply again and the changeset to
be "hidden". If we do not run the logic unfiltered it could failed to fetch the
phase of a newly filtered changeset.
Obsolescence marker can represent this situation just fine. The old
version is marked as precursor of the new changeset. All its
descendants become "unstable".
If obsolescence is not enabled we keep the current behavior of
aborting. This new behavior only applies when obsolete is
enabled and is subject to future discussion and changes.
A type mismatch caused the search for the other head to fail. The code is
fragile, and instead it ended up using the 'first' bookmark head, but the
ordering is undefined and it could thus randomly use the wrong bookmarkhead
and fail with:
$ hg up -q -C e@diverged
$ hg merge
abort: merging with a working directory ancestor has no effect
Before this patch, enabling strict command processing (ui.strict=True)
meant that 'hg bookmark NAME', as referenced several places in the
documentation, would not work. This adds 'bookmark' as an explicit alias
to 'bookmarks'.
Starting with 049792af94d6, users are no longer able to update a
working copy to a branch named with a "bad" character (such as ':').
Prior to v2.4, it was possible to create branch names using "bad"
characters, so this breaks backwards compatibility.
Mercurial must allow users to update to existing branches with bad
names. However, it should continue to prevent the creation of new
branches with bad names.
A test was added to confirm that 'hg update' works as expected. The
test uses a bundled repo that was created with an earlier version of
Mercurial.
'*' causes the resulting RE to match 0 or more repetitions of the preceding RE:
>>> bool(re.search('.*', ''))
>>> True
This causes an infinite loop because currently we're only checking if there was
a match without looking at where we are in the searched string.
Successors set are an important part of obsolescence. It is necessary to detect
and solve divergence situation. This changeset add a core function to compute
them, a debug command to audit them and solid test on the concept.
Check function docstring for details about the concept.
This changes graft to explicitly track the progression of commits it
makes, and updates it's idea of the current node based on it's last
commit, rather than from the working copy parent. This should have no
effect on the value of current since we were reading the working copy
parent immediately after commiting to it.
The motivation for this change is that a subsequent patch will break
the current node and working copy relationship. Splitting this out
into a separate patch will make that one more readible.
This moves the logic for generating the commit metadata ahead of the
merge operation. The only purposae of this patch is to make
subsequent patches easier to read, and there should be no behavior
changes.
scmutil.checknewlabel takes a repo object as its first argument.
When the call to this function was added in 4d438984605c, the
first argument was mistakenly set to 'None'.
The bisect command does not have an option to limit itself only to
subdirectories, but it's possible to use revsets for the --skip option
for the same effect. Given the relative obscurity of revsets, it helps
to have this as another example for bisect.
'*' causes the resulting RE to match 0 or more repetitions of the preceding RE:
>>> bool(re.search('.*', ''))
>>> True
This causes an infinite loop because currently we're only checking if there was
a match without looking at where we are in the searched string.
Bookmarks persistence still showed a fair amount of its legacy as a
monkeypatching extension. This encapsulates all bookmarks
serialization and parsing in a single class, and offers a single
location where other bookmarks storage engines can be substituted
in. As a result, many files no longer import the bookmarks module,
which strikes me as an encapsulation win.
This doesn't do anything to the current bookmark state yet, but I'm
hoping put that in the bmstore class as well.
ui contains repo specific configuration, so do not use it when there is a repo.
But pass it to hg.peer when there is no repo. Then it only contains global
configuration.
Before this patch, there is no information about whether help document
is fully displayed or not.
So, some users seem to misunderstand "-v" for "hg help" just as "the
option to show list of global options": experience on "hg help -v" for
some commands not containing verbose containers may strengthen this
misunderstanding.
Such users have less opportunity for noticing omitted help document,
and this may cause insufficient understanding about Mercurial.
This patch indicates help omitting, if help document is not fully
displayed.
For command help, the message below is displayed at the end of help
output, if help document is not fully displayed:
use "hg -v help xxxx" to show more complete help and the global
options
and otherwise:
use "hg -v help xxxx" to show the global options
For topics and extensions help, the message below is displayed, only
if help document is not fully displayed:
use "hg help -v xxxx" to show more complete help
This allows users to know whether there is any omitted information or
not exactly, and can trigger "hg help -v" invocation.
This patch causes formatting help document twice, to switch messages
one for omitted help, and another for not omitted. This decreases
performance of help document formatting, but it is not mainly focused
at help command invocation, so this wouldn't become problem.
This options allows to specify the `flag` part of obsolete markers. For details
about marker flags, check the `mercurial/obsolete.py` documentation. Some random
flag are added to a marker to test this feature.
This factors out the checks from tags and bookmarks, and newly applies
the same prohibitions to branches. checknewlabel takes a new parameter,
kind, indicating the kind of label being checked.
Test coverage is added for all three types of labels.
For now the new function only checks to make sure the new label name
isn't a reserved name ('tip', '.', or 'null'). Eventually more of the
checks will be unified between the different types of labels.
The `tag` command is trivially updated to use it. Updating branches and
bookmarks to use it is slightly more invasive and thus reserved for
later patches.
The recently introduced message was:
no unresolved files; you may continue your unfinished operation
This had three problems:
- looks a bit like an error message because it's not saying "we've
just resolved the last file"
- refers to "unfinished operation", which won't be the case with
"update" or "merge"
- introduces semicolons to error messages, which is stylistically
questionable
I've simplified this to:
no more unresolved files
In the future, if we want to prompt someone to continue a particular operation, we should use
a hint style:
no more unresolved files
(use 'hg graft --continue' to finish grafting)
When using resolve, users often have to consult with the output of |hg
resolve -l| to see if any unresolved files remain. This step is tedious
and adds overhead to resolving.
This patch will notify a user if there are no unresolved files remaining
after executing |hg resolve|::
no unresolved files; you may continue your unfinished operation
The patch stops short of telling the user exactly what command should be
executed to continue the unfinished operation. That is because this
information is not currently captured anywhere. This would make a
compelling follow-up feature.
Previously, if the paths specified as arguments to |hg resolve| were
invalid, they were silently ignored and a no-op would ensue.
This patch fixes that in some scenarios.
If none of the paths specified to |hg resolve| match a path that is in
mergestate, a warning will be emitted.
Ideally, a warning would be emitted for every path/pattern specified
that doesn't match anything. To achieve this would require significant
refactoring of the matching subsystem. That work is beyond the scope of
this patch series. Something is better than nothing and this patch
gets us something.
The resolve command is only relevant when mergestate is present.
This patch will make resolve abort when no mergestate is present.
This change will let people know when they are using resolve when they
shouldn't be. This change will let people know when their use of resolve
doesn't do anything.
Previously, |hg resolve -m| would allow mergestate to be created. This
patch now forbids that. Strictly speaking, this is backwards
incompatible. The author of this patch believes creating mergestate via
resolve doesn't make much sense and this side-effect was unintended.
Before this patch, "localrepository.tag()" doesn't take "editor"
argument, and this prevents callers from passing "editor" argument to
"localrepository.commit()" invoked internally.
This patch adds "editor" argument to "localrepository.tag()" (and
"_tag()", too), and makes "commands.tag()" invoke it with "editor"
argument.
This patch also omits explicit "localrepository.savecommitmesssage()"
invocation, because "localrepository.commit()" will invoke specified
"editor" and save edited commit message into ".hg/last-message.txt"
automatically.
Options like --delete and --rename are incompatible with each
other. In this case we abort. We do not abort if the result is a nullop.
Nullops are: '--delete --inactive', '--delete --force'.
This allows the user to set different colors for each phase, e.g.
[color]
changeset.public = blue
changeset.draft = green
changeset.secret = red
In addition, this doesn't affect current configuration for custom log.changeset
colors, but rather adds the option for users that want to visually see which
changesets are amendable.
Maintain a whitelist of commands to infer the repo for instead. The whitelist
contains those commands that take file(s) in the working dir as arguments.
a0d2da57b726 added this help text to hg bookmark:
If no NAME is given, the current active bookmark will be marked inactive.
But that was never actually the case.
Originally spotted by Idan Kamara <idankk86@gmail.com>.
Before this patch, there is no information about what users should (or
can) do for recovery from corruption of repositories.
This patch adds URL of the Mercurial Wiki page explaining about
recovery from corruption.
At the moment the resolve command doesn't save progress during the resolve process. In example if you try to resolve 100 conflicting files and interrupt the process (e.g., you close the external merge tool) after resolving 50 files you'll end up with 100 unresolved conflicts. Saving the progress helps a lot with long going merges. It's easy to achieve same behavior with simple script that calls resolve command for each unresolved file but it makes sense to make such behavior a default
If all heads are bookmarks, merge fails to find what node to merge
with (throws an IndexError while indexing into the non-bookmark heads
list) as of 208ca72b9343. This catches that case and prints an error
to specify a rev explicitly.
This makes the 'additional help topics' list consistent with the output from
keyword search (for instance subrepo/subrepos).
The sorting by longest name was introduced in 4cbe49492ad3. There might have
been a good reason for it back then, but now it seems like a better idea to
place the preferred name first in the list in helptable.
If you've got this graph:
0-1-2
\
3
and 3 is checked out, 2 is bookmarked with "broken", and you do "hg
strip 2", the bookmark will move to 3, not 1. That's always struck me
as a bug.
This change makes bookmarks move to the tipmost ancestor of
the stripped set rather than the currently-checked-out revision, which
is what I always expected should happen.
Before this change, push would incorrectly fast-path the bundle
generation when extinct changesets are involved, because they are not
added to outgoing.excluded. The reason to do so are related to
outgoing.excluded being assumed to contain only secret changesets by
scmutil.nochangesfound(), when displaying warnings like:
changes found (ignored 9 secret changesets)
Still, outgoing.excluded seems like a good API to report the extinct
changesets instead of dedicated code and nothing in the docstring
indicates it to be bound to secret changesets. This patch adds extinct
changesets to outgoing.excluded and fixes scmutil.nochangesfound() to
filter the excluded node list.
Original version and test by Pierre-Yves.David@ens-lyon.org
This change separates peer implementations from the repository implementation.
localpeer currently is a simple pass-through to localrepository, except for
legacy calls, which have already been removed from localpeer. This ensures that
the local client code only uses the most modern peer API when talking to local
repos.
Peers have a .local() method which returns either None or the underlying
localrepository (or descendant thereof). Repos have a .peer() method to return
a freshly constructed localpeer. The latter is used by hg.peer(), and also to
allow folks to pass either a peer or a repo to some generic helper methods.
We might want to get rid of .peer() eventually.
The only user of locallegacypeer is debugdiscovery, which uses it to pose as a
pre-setdiscovery client. But we decided to leave the old API defined in
locallegacypeer for clarity and maybe for other uses in the future.
It might be nice to actually define the peer API directly in peer.py as stub
methods. One problem there is, however, that localpeer implements
lock/addchangegroup, whereas the true remote peers implement unbundle.
It might be desireable to get rid of this distinction eventually.
This introduces a peer method into all repository classes, which currently
simply returns self. It also changes hg.repository so it now raises an
exception if the supplied paths does not resolve to a localrepo or descendant.
Finally, all call sites are changed to use the peer and local methods as
appropriate, where peer is used whenever the code is dealing with a remote
repository (even if it's on local disk).
Plain 'hg help rollback' now looks like this:
$ hg help rollback
hg rollback
roll back the last transaction (dangerous)
This command should be used with care. There is only one level of
rollback, and there is no way to undo a rollback. It will also restore
the dirstate at the time of the last transaction, losing any dirstate
changes since that time. This command does not alter the working
directory.
Transactions are used to encapsulate the effects of all commands that
create new changesets or propagate existing changesets into a repository.
This command is not intended for use on public repositories. Once changes
are visible for pull by other users, rolling a transaction back locally
is ineffective (someone else may already have pulled the changes).
Furthermore, a race is possible with readers of the repository; for
example an in-progress pull from the repository may fail if a rollback is
performed.
Returns 0 on success, 1 if no rollback data is available.
options:
-n --dry-run do not perform actions, just print output
-f --force ignore safety measures
--mq operate on patch repository
use "hg -v help rollback" to show more info
Marker are now written as soon as possible but within a transaction. Using a
transaction ensure a proper behavior on error and rollback compatibility.
Flush logic are not necessary anymore and are dropped from lock release.
With this changeset, the obsstore is open, written and closed for every single
added marker. This is expected to be highly inefficient and batched write should
be implemented "quickly".
Another issue is that every flush of the file will invalidate the obsstore
filecache and trigger a full re instantiation of the repo.obsstore attribute
(including, reading and parsing entry). This is also expected to be highly
inefficient and proper filecache operation should be implemented "quickly" too.
A side benefit of the filecache issue is that repo.obsstore object is properly
invalidated on transaction abortion.
This replicates the strategy of rebase, which postpones setparents and
duplicatecopies after checking the merge stats.
Without the second parent, resolve cannot redo merge.
This patch fixes the broken formatting of keyword search results. Some blank
lines were missing from the RST markup, which caused markup to be printed.
Accepting a variable number of arguments as the old API did is
deeply ugly, particularly as it means the API can't be extended
with new arguments. Partly as a result, we have at least three
different implementations of the same ancestors algorithm (!?).
Most callers were forced to call ancestors(*somelist), adding to
both inefficiency and ugliness.
This patch changes the function which generates help text about commands and
options to use RST formatting. Tables describing options have been formatted
using RST table markup for some time already, so their appearance does not
change. Command lists, however, change appearance.
To format non-verbose command lists, RST field list markup was chosen, because
it resembles the old format:
<http://docutils.sourceforge.net/docs/user/rst/quickref.html#field-lists>
In the old (hand-coded) format of non-verbose command lists, the left column is
12 characters wide. Our minirst implementation formats field lists with a left
column 14 characters wide, so this patch changes the appearance of help output
correspondingly:
<http://markmail.org/message/krl4cxopsnii7s6z?q=mercurial+reinert+from:%22Olav+Reinert%22&page=2>
The minirst markup most closely resembling the old verbose command lists is
definition lists. But using it would cause a blank line to be inserted between
each command definition, making the output excessively long, and no more
useful than before. To avoid this, I chose to use field lists also for verbose
command help, resulting in output like this example:
add add the specified files on the next commit
annotate, blame
show changeset information by line for each file
clone make a copy of an existing repository
commit, ci commit the specified files or all outstanding changes
diff diff repository (or selected files)
export dump the header and diffs for one or more changesets
forget forget the specified files on the next commit
init create a new repository in the given directory
log, history show revision history of entire repository or files
merge merge working directory with another revision
phase set or show the current phase name
pull pull changes from the specified source
push push changes to the specified destination
qdiff diff of the current patch and subsequent modifications
qinit init a new queue repository (DEPRECATED)
qnew create a new patch
qpop pop the current patch off the stack
qpush push the next patch onto the stack
qrefresh update the current patch
remove, rm remove the specified files on the next commit
serve start stand-alone webserver
status, st show changed files in the working directory
summary, sum summarize working directory state
update, up, checkout, co
update working directory (or switch revisions)
This change is a move towards generating all help text as a list of strings
marked up with RST.
This is achieved by acting as if the user had given -r<rev> for each head rev
of outgoing changesets on the command line, as well as appropriate
--base <rev>.
The discovery information is computed as normal, and then adjusted as above.
Bookmarks will behave more like named branches when merge tries to pick
a revision to merge.
Bookmarks now to respect the current bookmarks. Bookmarks will not
accidentally merged with unnamed heads or other bookmarks. However merge
can pick heads with diverging bookmarks and pick those automatically.
We end up with two cases for picking a revision to merge:
(1) In case of an current bookmark, merge can pick a branch head that has a
diverged bookmark
(2) In case of no current bookmark, merge can pick a branch head that does not
have a bookmark.
The original motivation was changectx.phase() had special logic to
correctly lookup in repo._phaserev, including invalidating it when
necessary. And at other places, repo._phaserev was accessed directly.
This led to the discovery that phases state including _phaseroots,
_phaserev and _dirtyphase was manipulated in localrepository.py,
phases.py, repair.py, etc. phasecache helps encapsulating that.
This patch replaces all phase state in localrepo with phasecache and
adjust related code except for advance/retractboundary() in phases.
These still access to phasecache internals directly. This will be
addressed in a followup.
There is currently no clear link between the help for log
and the help on templates. The log option is --template
but the template help is 'help templating' or 'help templates'.
This patch makes 'hg help template' work and also adds a
note into the log help explaining where to find more info.
The fix introduced in 3509b9cf8f86 was only partially successful. It is correct
to turn dirstate 'm' merge records into normal/dirty ones but copy records are
lost in the process. To adjust them as well, we need to look in the first
parent manifest to know which files were added and preserve only related
records. But the dirstate does not have access to changesets, the logic has to
moved at another level, in localrepo.
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.
Checking the bundle type late in the command's execution can mean
that we do work for a long time before complaining about incorrect
user input and aborting. Guess how I discovered this.
