Changesets in which a given set of fields match the set of fields in the selected revision or set. To match more than one field pass the list of fields to match separated by spaces e. Regular revision fields are description , author , branch , date , files , phase , parents , substate , user and diff. Note that author and user are synonyms. Two revisions matching their diff will also match their files. Special fields are summary and metadata : summary matches the first line of the description.
You can match more than one field at a time. Pattern matching is supported for namespace. If any of specified revisions is not present in the local repository, the query is normally aborted. But this predicate allows the query to continue even in such cases.
Sort set by keys. The default sort order is ascending, specify a key as -key to sort in descending order. The topo sort order cannot be combined with other sort keys. This sort takes one optional argument, topo. New predicates known as "aliases" can be defined, using any combination of existing predicates or other aliases. An alias definition looks like:. Arguments of the form a1 , a2 , etc. Command line equivalents for hg log :. Changesets between tags 1. Changesets mentioning "bug" or "issue" that are not in a tagged release:.
Update to the commit that bookmark is pointing to, without activating the bookmark this works because the last revision of the revset is used :. Show diff between tags 1. It is common for machines as opposed to humans to consume Mercurial. This help topic describes some of the considerations for interfacing machines with Mercurial.
Executing hg processes is very similar to how humans interact with Mercurial in the shell. It should already be familiar to you. By default, this will start a "hgweb" HTTP server. For more, see hg help hgweb.
This is because there is significant overhead to spawn new Python processes. As documented in hg help environment , various environment variables influence the operation of Mercurial. The following are particularly relevant for machines consuming Mercurial:.
If not set, Mercurial's output could be influenced by configuration settings that impact its encoding, verbose mode, localization, etc. It is highly recommended for machines to set this variable when invoking hg processes. If not set, the locale used by Mercurial will be detected from the environment.
If the determined locale does not support display of certain characters, Mercurial may render these character sequences incorrectly often by using "? Explicitly setting this environment variable is a good practice to guarantee consistent results. If not set, Mercurial will inherit config options from config files using the process described in hg help config.
This includes inheriting user or system-wide config files. Note that these approaches can have unintended consequences, as the user and system config files often define things like the username and extensions that may be required to interface with a repository. It is common for machines to need to parse the output of Mercurial commands for relevant data.
This section describes the various techniques for doing so. Likely the simplest and most effective solution for consuming command output is to simply invoke hg commands as you would as a user and parse their output.
The output of many commands can easily be parsed with tools like grep , sed , and awk. A potential downside with parsing command output is that the output of commands can change when Mercurial is upgraded. While Mercurial does generally strive for strong backwards compatibility, command output does occasionally change. Having tests for your automated interactions with hg commands is generally recommended, but is even more important when raw command output parsing is involved.
For more, see hg help templates. Templates are useful for explicitly controlling output so that you get exactly the data you want formatted how you want it. If parsing raw command output is too complicated, consider using templates to make your life easier. These are useful for producing output that is machine readable as-is. The json and xml styles are considered experimental.
While they may be attractive to use for easily obtaining machine-readable output, their behavior may change in subsequent versions. These styles may also exhibit unexpected results when dealing with certain encodings. Mercurial treats things like filenames as a series of bytes and normalizing certain byte sequences to JSON or XML with certain encoding settings can lead to surprises. If so, this interface layer may perform parsing for you, saving you the work of implementing it yourself.
Commands often have varying output verbosity, even when machine readable styles are being used e. Revisions sets is a functional query language for selecting a set of revisions. Think of it as SQL for Mercurial repositories. Revsets are useful for querying repositories for specific data. See hg help revsets for more. The share extension provides functionality for sharing repository data across several working copies. It can even automatically "pool" storage for logically related repositories when cloning.
Configuring the share extension can lead to significant resource utilization reduction, particularly around disk space and the network. This is especially true for continuous integration CI environments. See hg help -e share for more. Subrepositories let you nest external repositories or projects into a parent Mercurial repository, and make commands operate on them as a group. Nested repository checkouts.
They can appear anywhere in the parent working directory. Nested repository references. They are defined in.
Mercurial subrepositories are referenced like:. The source can also reference a filesystem path. Note that. Nested repository states. Mercurial automatically record the nested repositories states when committing in the parent repository. Clone or checkout the external projects where you want it to live in the parent repository. At this point, the subrepository is tracked and the next commit will record its state in. Subrepos do not automatically track the latest changeset of their sources.
Instead, they are updated to the changeset that corresponds with the changeset checked out in the top-level changeset. This is so developers always get a consistent set of compatible code and libraries when they update. Thus, updating subrepos is a manual process. Simply check out target subrepo at the desired revision, test in the top-level repo, then commit in the parent repository to record the new combination.
To remove a subrepository from the parent repository, delete its reference from. A subrepository source location may change during a project life, invalidating references stored in the parent repository history. To fix this, rewriting rules can be defined in parent repository hgrc file or in Mercurial configuration.
See the [subpaths] section in hgrc 5 for more details. Mercurial allows you to customize output of commands through templates.
You can either pass in a template or select an existing template-style from the command line, via the --template option. You can customize output for any "log-like" command: log, outgoing, incoming, tip, parents, and heads. Some built-in styles are packaged with Mercurial. These can be listed with hg log --template list. Example usage:.
Strings in curly braces are called keywords. The availability of keywords depends on the exact context of the templater. These keywords are usually available for templating a log-like command:. The "date" keyword does not produce human-readable output. If you want to use a date in your output, you can use a filter to process it.
Filters are functions which return a string based on the input variable. Be sure to use the stringify filter first when you're applying a string-input filter to a list-like input variable. You can also use a chain of filters to get the desired output:. Note that a filter is nothing more than a function call, i. New keywords and functions can be defined in the templatealias section of a Mercurial configuration file:.
It's also possible to specify complete template strings, using the templates section. The syntax used is the general template string syntax. A template defined in templates section can also be referenced from another template:. For example, a template defined as templates. Paths in the local filesystem can either point to Mercurial repositories or to bundle files as created by hg bundle or hg incoming --bundle.
See also hg help paths. An optional identifier after indicates a particular branch, tag, or changeset to use from the remote repository. See also hg help revisions. SSH requires an accessible shell account on the destination machine and a copy of hg in the remote path or specified with as remotecmd. Use an extra slash at the start of a path to specify an absolute path:.
Alternatively specify "ssh -C" as your ssh command in your configuration file or with the --ssh command line option. These URLs can all be stored in your configuration file with path aliases under the [paths] section like so:.
You can then use the alias for any command that uses a URL for example hg pull alias1 will be treated as hg pull URL1. Two path aliases are special because they are used as defaults when you do not provide the URL to a command:.
This section contains help for extensions that are distributed together with Mercurial. Help for other extensions is available in the help system. This hook makes it possible to allow or deny write access to given branches and paths of a repository when receiving incoming changesets via pretxnchangegroup and pretxncommit. The authorization is matched based on the local user name on the system where the hook runs, and not the committer of the original changeset since the latter is merely informative.
The acl hook is best used along with a restricted shell like hgsh, preventing authenticating users from doing anything other than pushing or pulling.
The hook is not safe to use if users have interactive shell access, as they can then disable the hook. Nor is it safe if remote users share an account, because then there is no way to distinguish them. Use the acl. Keys in these sections can be either:. Keys in these sections accept a subtree pattern with a glob syntax by default. The corresponding values follow the same syntax as the other sections above. Group names must be prefixed with an symbol.
Specifying a group name has the same effect as specifying all the users in that group. You can define group members in the acl. If a group name is not defined there, and Mercurial is running under a Unix-like system, the list of users will be taken from the OS. Otherwise, an exception will be raised. Suppose there's a branch that only a given user or group should be able to push to, and you don't want to restrict access to any other branch that may be created.
The "! In the examples below, we will: 1 Deny access to branch "ring" to anyone but user "gollum" 2 Deny access to branch "lake" to anyone but members of the group "hobbit" 3 Deny access to a file to anyone but user "gollum".
This extension provides an amend command that is similar to commit --amend but does not prompt an editor. Similar to hg commit --amend , but reuse the commit message without invoking editor, unless --edit was set.
See hg help commit for more details. The threshold at which a file is considered a move can be set with the automv. This option takes a percentage between 0 disabled and files must be identical , the default is Logs event information to. The events that get logged can be configured via the blackbox. This hook extension adds comments on bugs in Bugzilla when changesets that refer to bugs by Bugzilla ID are seen. The comment is formatted using the Mercurial template mechanism.
The bug references can optionally include an update for Bugzilla of the hours spent working on the bug. Bugs can also be marked fixed. Writing directly to the database is susceptible to schema changes, and relies on a Bugzilla contrib script to send out bug change notification emails.
This script runs as the user running Mercurial, must be run on the host with the Bugzilla install, and requires permission to read Bugzilla configuration details and the necessary MySQL user and password to have full access rights to the Bugzilla database. For these reasons this access mode is now considered deprecated, and will not be updated for new Bugzilla versions going forward.
Only adding comments is supported in this access mode. Comments are added under that username. Since the configuration must be readable by all Mercurial users, it is recommended that the rights of that user are restricted in Bugzilla to the minimum necessary to add comments.
Marking bugs fixed requires Bugzilla 4. The From: address in the email is set to the email address of the Mercurial user, so the comment appears to come from the Mercurial user. In the event that the Mercurial user email is not recognized by Bugzilla as a Bugzilla user, the email associated with the Bugzilla username used to log into Bugzilla is used instead as the source of the comment.
Marking bugs fixed works on all supported Bugzilla versions. Comments are made under the given username or the user associated with the apikey in Bugzilla. Template to use when formatting comments. Overrides style if specified.
In addition to the usual Mercurial keywords, the extension specifies:. Path of file containing Mercurial committer email to Bugzilla user email mappings. If specified, the file should contain one mapping per line:.
The [usermap] section is used to specify mappings of Mercurial committer email to Bugzilla user email. See also bugzilla. In addition, the Mercurial email settings must be configured. See the documentation in hgrc 5 , sections [email] and [smtp]. Bug comments are sent to the Bugzilla email address bugzilla my-project. MySQL example configuration. This has a local Bugzilla 3. The censor command instructs Mercurial to erase all content of a file at a given revision without updating the changeset hash.
Censored nodes can interrupt mercurial's typical operation whenever the excised data needs to be materialized. Others, like hg verify and hg update , must be capable of tolerating censored data to continue to function in a meaningful way. Such commands only tolerate censored file revisions if they are allowed by the "censor.
This extension is deprecated. You should use hg log -r "children REV " instead. Print the children of the working directory's revisions. If a file argument is given, revision in which the file was last changed after the working directory revision or the argument to --rev if given is printed.
Please use hg log instead:. See hg help log and hg help revsets. This command will display a histogram representing the number of changed lines or revisions, grouped according to the given template. The default template will group changes by author. The --dateformat option may be used to group the results by date instead. Statistics are based on the number of changed lines, or alternatively the number of matching revisions if the --changesets option is specified.
It is possible to map alternate email addresses to a main address by providing a file using the following format:. Such a file may be specified with the --aliases option, otherwise a. Traditionally, the server, in response to a client's request to clone, dynamically generates a bundle containing the entire repository content and sends it to the client. There is no caching on the server and the server will have to redundantly generate the same outgoing bundle in response to each clone request.
For servers with large repositories or with high clone volume, the load from clones can make scaling the server challenging and costly.
This extension provides server operators the ability to offload potentially expensive clone load to an external service. Here's how it works. Instead of the server generating full repository bundles for every clone request, it generates full bundles once and they are subsequently reused to bootstrap new clones. The server may still transfer data at clone time.
Strictly speaking, using a static file hosting server isn't required: a server operator could use a dynamic service for retrieving bundle data. However, static file hosting services are simple and scalable and should be sufficient for most needs. Bundle files can be generated with the hg bundle command. Typically hg bundle --all is used to produce a bundle of the entire repository. These are bundle files that are extremely efficient to produce and consume read: fast.
However, they are larger than traditional bundle formats and require that clients support the exact set of repository data store formats in use by the repository that created them.
Typically, a newer server can serve data that is compatible with older clients. However, streaming clone bundles don't have this guarantee. Server operators need to be aware that newer versions of Mercurial may produce streaming clone bundles incompatible with older Mercurial versions. A server operator is responsible for creating a.
If this file does not exist, the repository will not advertise the existence of clone bundles when clients connect. Both keys and values are URI encoded. All non-uppercase keys can be used by site installations. An example use for custom properties is to use the datacenter attribute to define which data center a file is hosted in. Clients could then prefer a server in the data center closest to them.
These are string values that are accepted by the "--type" argument of hg bundle. See mercurial. Clients will automatically filter out specifications that are unknown or unsupported so they won't attempt to download something that likely won't apply.
The actual value doesn't impact client behavior beyond filtering: clients will still sniff the bundle type from the header of downloaded files. Use of this key is highly recommended , as it allows clients to easily skip unsupported bundles. If this key is not defined, an old client may attempt to apply a bundle that it is incapable of reading. SNI allows servers to use multiple certificates on the same IP. It is somewhat common in CDNs and other hosting providers. Older Python versions do not support SNI.
Defining this attribute enables clients with older Python versions to filter this entry without experiencing an opaque SSL failure at connection time. If this is defined, it is important to advertise a non-SNI fallback URL or clients running old Python releases may not be able to clone with the clonebundles facility.
Manifests can contain multiple entries. Assuming metadata is defined, clients will filter entries from the manifest that they don't support. The remaining entries are optionally sorted by client preferences ui.
The client then attempts to fetch the bundle at the first URL in the remaining list. Errors when downloading a bundle will fail the entire clone operation: clients do not automatically fall back to a traditional clone. The reason for this is that if a server is using clone bundles, it is probably doing so because the feature is necessary to help it scale.
In other words, there is an assumption that clone load will be offloaded to another service and that the Mercurial server isn't responsible for serving this clone load. If that other service experiences issues and clients start mass falling back to the original Mercurial server, the added clone load could overwhelm the server due to unexpected load and effectively take it offline.
Not having clients automatically fall back to cloning from the original server mitigates this scenario. Because there is no automatic Mercurial server fallback on failure of the bundle hosting service, it is important for server operators to view the bundle hosting service as an extension of the Mercurial server in terms of availability and service level agreements: if the bundle hosting service goes down, so does the ability for clients to clone.
Note: clients will see a message informing them how to bypass the clone bundles facility when a failure occurs. So server operators should prepare for some people to follow these instructions when a failure occurs, thus driving more load to the original Mercurial server when the bundle hosting service fails. If no revision is given, all revisions will be converted. Otherwise, convert will only import up to the named revision given in a format understood by the source.
If no destination directory name is specified, it defaults to the basename of the source with -hg appended. If the destination repository doesn't exist, it will be created. By default, all sources except Mercurial will use --branchsort. Mercurial uses --sourcesort to preserve original revision numbers order. Sort modes have the following effects:. If the file doesn't exist, it's automatically created. It's updated on each commit copied, so hg convert can be interrupted and can be run repeatedly to copy new commits.
The authormap is a simple text file that maps each source commit author to a destination commit author. It is handy for source SCMs that use unix logins to identify authors e. One line per author mapping and the line format is:.
The filemap is a file that allows filtering and remapping of files and directories. Each line can contain one of the following directives:. Comment lines start with. A specified path matches if it equals the full relative name of a file or one of its parent directories. The include or exclude directive with the longest matching path applies, so line order does not matter.
The include directive causes a file, or all files under a directory, to be included in the destination repository. The default if there are no include statements is to include everything. If there are any include statements, nothing else is included. The exclude directive causes files or directories to be omitted.
The rename directive renames a file or directory if it is converted. To rename from a subdirectory into the root of the repository, use. It will make a full conversion of all files, not just the ones that have changed. Files that already are correct will not be changed. This can be used to apply filemap changes when converting incrementally. This is currently only supported for Mercurial and Subversion.
The splicemap is a file that allows insertion of synthetic history, letting you specify the parents of a revision. This is useful if you want to e. Each entry contains a key, followed by a space, followed by one or two comma-separated values:. The key is the revision ID in the source revision control system whose parents should be modified same format as a key in.
The values are the revision IDs in either the source or destination revision control system that should be used as the new parents for that node. For example, if you have merged "release The branchmap is a file that allows you to rename a branch when it is being brought in from whatever external repository. When used in conjunction with a splicemap, it allows for a powerful combination to help fix even the most badly mismanaged repositories and turn them into nicely structured Mercurial repositories.
The branchmap contains lines of the form:. No whitespace is allowed in the new branch name. This can be used to for instance move code in one repository from "default" to a named branch. The Mercurial source recognizes the following configuration options, which you can set on the command line with --config :. CVS source will use a sandbox i.
Direct access to the repository files is not needed, unless of course the repository is :local:. The conversion uses the top level directory in the sandbox to find the CVS repository, and then uses CVS rlog commands to find files to convert. This means that unless a filemap is given, all files under the starting directory will be converted, and that any directory reorganization in the CVS sandbox is ignored. The following options can be used with --config :. An additional "debugcvsps" Mercurial command allows the builtin changeset merging code to be run without doing a conversion.
Its parameters and output are similar to that of cvsps 2. Please see the command help for more details. Default trunk , branches and tags values can be overridden with following options. Set them to paths relative to the source URL, or leave them blank to disable auto detection. The following options can be set with --config :. Source history can be retrieved starting at a specific revision, instead of being integrally converted.
Only single branch conversions are supported. Git submodules are converted to Git subrepos in Mercurial. The default is This is very expensive for large projects, and is only effective when convert.
The default is False. Increasing this will make rename and copy detection more accurate but will significantly slow down computation on large projects. The option is only relevant if convert. Git commits have separate author who wrote the commit and committer who applied the commit fields. Not all destinations support separate author and committer fields including Mercurial. This config option controls what to do with these author and committer fields during conversion.
A value of messagedifferent will append a committer When a prefix is specified, a space will always be inserted between the prefix and the value. This value is mutually exclusive with messagedifferent. Only references to the author will remain.
Actions that add references to the committer will have no effect when this is set. Other actions that add references to the committer will still take effect when this is set. Some Git repositories store extra metadata in commits.
By default, this non-default metadata will be lost during conversion. Setting this config option can retain that metadata. Some built-in keys such as parent and branch are not allowed to be copied. The default is 'remote'. The default is True.
Default is False. The Perforce P4 importer can be given a p4 depot path or a client specification as source. It will convert all files in the source to a flat Mercurial repository, ignoring labels, branches and integrations.
Note that when a depot path is given you then usually should specify a target directory, because otherwise the target may be named The Mercurial destination will recognize Mercurial subrepositories in the destination directory, and update the.
Converting a repository with subrepositories requires converting a single repository at a time, from the bottom up. This extension allows you to manage the type of line endings CRLF or LF that are used in the repository and in the local working directory.
The extension reads its configuration from a versioned. It uses two sections, [patterns] and [repository]. The [patterns] section specifies how line endings should be converted between the working directory and the repository. The format is specified by a file pattern. The first match is used, so put more specific patterns first. Note that BIN do nothing to line endings is Mercurial's default behavior; it is only needed if you need to override a later, more general pattern.
The optional [repository] section specifies the line endings to use for files stored in the repository. It has a single setting, native , which determines the storage line endings for files declared as native in the [patterns] section. The default is LF. For example, this means that on Windows, files configured as native CRLF by default will be converted to LF when stored in the repository. The rules will first apply when files are touched in the working directory, e.
The extension uses an optional [eol] section read from both the normal Mercurial configuration files and the. You can use that section to control the overall behavior. There are three settings:. The extension provides cleverencode: and cleverdecode: filters like the deprecated win32text extension does. This means that you can disable win32text and enable eol and your filters will still work.
You only need to these filters until you have prepared a. The win32text. The hook will lookup the expected line endings from the. To forbid them completely, use the eol. These hooks are best used as pretxnchangegroup hooks. See hg help patterns for more information about the glob patterns used. The extdiff Mercurial extension allows you to use external programs to compare revisions, or revision with working directory.
This can be done by right clicking on the commit in commit history you want to update to and selecting Update from the context menu. If you have local uncommitted changes you may be prompted to either discard or shelve those changes.
The idea of shelving changes is to temporarily move changes made to your working directory in another location so they can be restored later. To open the shelve tool select the working directory in commit history and then click this icon just below the commit message window:. On the left column you should see a list of changes in the working directory.
Before you can start moving changes across you will need to create a new shelf by clicking the icon just above the shelf dropdown on the left side of the right column. You can now click the Move all files or Move selected files icons at the top to move file changes between the working directory and the shelf. You can even select parts of a file change by selecting the file and then ticking underneath what chunks you want to copy and then clicking the Move selected chunks button as illustrated in the image above.
Note you can create more than one shelf, and even select a shelf in the dropdown in the left column to move changes between shelves. Clear just empties the shelf or working directory of all changes, and delete will delete the shelf.
Sometimes if when you try to restore changes you have shelved to your working directory you may see this:. How this dialog works is in top box it shows the current file in the working directory which you can edit here. Underneath are two columns, the first column is a list of the changes or chunks for the file that are in the shelf, the second column shows what the change is for the selected chunk.
When you have finished you click save. From here you can create new branches or close existing branches, this change happens once you have completed the commit. Note you filter the commit history to only show commits for a specified branch, first select the Filter graph with revision sets icon from the toolbar at the top.
When the filter toolbar appears you can select the branch you want from the dropdown on the right hand side. When you want to merge between branches update to the branch you want to merge the changes into by selecting the latest commit then right click and select Update. Then you select the head of the other branch and then right click and select Merge with Local like below:. You will see a dialog called Prepare to merge here you may need to discard or shelve local uncomitted changes before continuing then click next.
If on the next screen you see this:. You have merge conflicts that need resolving, to resolve click the highlighted word Resolve and you should see this:. Usually you can just just select all the conflicted files and choose tool resolve, this is the dialog it shows if using KDiff3 if there is a conflict on a particular line:. On the left column A is the common ancestor for both heads, in the middle column B you have the current head you have updated to, and on the right column C is the head you a merging from.
And at the bottom shows the merged output, so here you can see the line that has caused the conflict. So toolbar you can select what lines you want from A, B or C. In this case looking at the diff we see we probably want the lines from B and C as shown:. Now that the first conflict is resolved we can click the triple down arrow in the toolbar to proceed to the next conflict:. Now for this conflict we also want to pick the lines from B and C as shown.
However here you can see that the output is invalid and needs to be manually fixed:. Once there are no more conflicts, the next conflict button is disabled, you can click save at the top and then close the window.
On this next screen you can enter the commit message and then click Commit Now. You are now done. To use graft you will need to enable the transplant extension. Graft allows you to copy one commit from one branch to another. Take for example this scenario:. You have now copied the commit:. Now you will see a dialog like this:. Here you can see a list of commits when the file was changed, which you can select to see what the changes were.
At the top of the bottom box you can toggle between three different views, the first two allow you to switch between diff style views patch and inline you can still right click the commit and select Diff to Parent to use a diffing tool like KDiff3. And the last view is called annotate which displays the whole file with the revision number on the left hand side of each line when that line was last changed, you can then hover over that line to see who made the commit and what the commit message was in the status bar.
Note that the revision numbers you see in your commit history can be different to the revision numbers other developers see in their local repository. This is simply because the numbers are incremental in the order the commits are made on your local repository.
For example if you made a commit and then pulled a new commit in and then merged before pushing your commit history will look like this:. Since extdiff did not support three way diff arguments until very recently and still does not support label arguments, you will likely have a better experience by disabling or deleting any extdiff configuration you may have. The visual diff system will directly use the selected diff tool unless the action you are attempting requires the use of the TortoiseHg visual diff window.
The list of conditions includes:. When the visual diff window is used, the temporary files are cleaned up when the dialog is closed. Thus it should be left open until you close all of your diff tool instances.
When your diff tool is launched directly, the temporary files are deleted when your tool exits. If your diff tool is launched directly to compare a working copy file, it will directly diff against the working file so you may modify it from within the diff tool.
If you are comparing multiple files, the visual diff system will make a snapshot of the working copy files and track their initial sizes and timestamps. When your diff tool exits, the system compares the sizes and timestamps and copies modified files back over the original working copies. In this way, you can still modify your working copy files from your visual diff tool even when performing directory comparisons.
When the visual diff window is used to compare working copy files, it always directly diffs against the working copy files since it always operates on a single file at a time. Deprecated since version 1. If you have a visual diff tool installed that is not supported by TortoiseHg, you can create a tool configuration for it in your user Mercurial.
When that is complete, you can add the extra keys used by TortoiseHg for visual diff:. If your diff tool cannot use the ancestor revision in any productive way, it is safe to leave it out of the diff3args command line.
If you create a new visual diff tool configuration, or improve upon an existing configuration, please email it to our development mailing list so it may be incorporated in a future release. These are configured in the site-wide mergepatterns.
0コメント