neulab/tldr huggingface dataset:
Rebase uses repeated merging to graft changesets from one part of history (the source) onto another (the destination). This can be useful for linearizing local changes relative to a master development tree.
Published commits cannot be rebased (see hg help phases).  To copy commits, see hg help graft.
If you don't specify a destination changeset (-d/--dest), rebase will use the same logic as hg merge to pick a destination.  if the current branch contains exactly one other head, the other head is merged with by default.  Otherwise, an explicit revision with which to merge with must be provided.  (destination changeset is not modified by rebasing, but new changesets are added as its descendants.)
Here are the ways to select changesets:
1. Explicitly select them using --rev.
2. Use --source to select a root changeset and include all of its descendants.
3. Use --base to select a changeset; rebase will find ancestors and their descendants which are not also ancestors of the destination.
4. If you do not specify any of --rev, --source, or --base, rebase will use --base . as above.
If --source or --rev is used, special names SRC and ALLSRC can be used in --dest. Destination would be calculated per source revision with SRC substituted by that single source revision and ALLSRC substituted by all source revisions.
Rebase will destroy original changesets unless you use --keep.  It will also move your bookmarks (even if you do).
Some changesets may be dropped if they do not contribute changes (e.g. merges from the destination branch).
Unlike merge, rebase will do nothing if you are at the branch tip of a named branch with two heads. You will need to explicitly specify source and/or destination.
If you need to use a tool to automate merge/conflict decisions, you can specify one with --tool, see hg help merge-tools.  As a caveat: the tool will not be used to mediate when a file was deleted, there is no hook presently available for this.
If a rebase is interrupted to manually resolve a conflict, it can be continued with --continue/-c, aborted with --abort/-a, or stopped with --stop.
• move "local changes" (current commit back to branching point) to the current branch tip after a pull:
hg rebase
• move a single changeset to the stable branch:
hg rebase -r 5f493448 -d stable
• splice a commit and all its descendants onto another part of history:
hg rebase --source c0c3 --dest 4cf9
• rebase everything on a branch marked by a bookmark onto the default branch:
hg rebase --base myfeature --dest default
• collapse a sequence of changes into a single commit:
hg rebase --collapse -r 1520:1525 -d .
• move a named branch while preserving its name:
hg rebase -r "branch(featureX)" -d 1.3 --keepbranches
• stabilize orphaned changesets so history looks linear:
hg rebase -r 'orphan()-obsolete()' -d 'first(max((successors(max(roots(ALLSRC) & ::SRC)^)-obsolete())::) + max(::((roots(ALLSRC) & ::SRC)^)-obsolete()))'
You can make rebase require a destination if you set the following config option:
[commands] rebase.requiredest = True
By default, rebase will close the transaction after each commit. For performance purposes, you can configure rebase to use a single transaction across the entire rebase. WARNING: This setting introduces a significant risk of losing the work you've done in a rebase if the rebase aborts unexpectedly:
[rebase] singletransaction = True
By default, rebase writes to the working copy, but you can configure it to run in-memory for better performance. When the rebase is not moving the parent(s) of the working copy (AKA the "currently checked out changesets"), this may also allow it to run even if the working copy is dirty:
[rebase] experimental.inmemory = True
Return Values:
Returns 0 on success, 1 if nothing to rebase or there are unresolved conflicts.
-s,--source <REV[+]> rebase the specified changesets and their descendants
-b,--base <REV[+]> rebase everything from branching point of specified changeset
-r,--rev <REV[+]> rebase these revisions
-d,--dest <REV> rebase onto the specified changeset
--collapse collapse the rebased changesets
-m,--message <TEXT> use text as collapse commit message
-l,--logfile <FILE> read collapse commit message from file
-k, --keep keep original changesets
--keepbranches keep original branch names
-D, --detach (DEPRECATED)
-i, --interactive (DEPRECATED)
--stop stop interrupted rebase
-c, --continue continue an interrupted rebase
-a, --abort abort an interrupted rebase
--auto-orphans <VALUE> automatically rebase orphan revisions in the specified revset (EXPERIMENTAL)
--confirm ask before applying actions
record commands to interactively select changes for commit/qrefresh (DEPRECATED)
The feature provided by this extension has been moved into core Mercurial as hg commit --interactive.
Commands Change creation qrecord interactively record a new patch:
hg qrecord [OPTION]... PATCH [FILE]...
See hg help qnew & hg help record for more information and usage.
record interactively select changes to commit:
hg record [OPTION]... [FILE]...
If a list of files is omitted, all changes reported by hg status will be candidates for recording.
If using the text interface (see hg help config), you will be prompted for whether to record changes to each modified file, and for files with multiple changes, for each change to use. For each query, the following responses are possible:
y - record this change n - skip this change e - edit this change manually
s - skip remaining changes to this file f - record remaining changes to this file
d - done, skip remaining changes and files a - record all changes to all remaining files q - quit, recording no changes
? - display help
This command is not available when committing a merge.
releasenotes generate release notes from commit messages (EXPERIMENTAL)
It is common to maintain files detailing changes in a project between releases. Maintaining these files can be difficult and time consuming. The hg releasenotes command provided by this extension makes the process simpler by automating it.
Commands Change navigation releasenotes parse release notes from commit messages into an output file:
hg releasenotes [-r REV] [-c] FILE
Given an output file and set of revisions, this command will parse commit messages for release notes then add them to the output file.
Release notes are defined in commit messages as ReStructuredText directives. These have the form:
.. directive:: title
Each directive maps to an output section in a generated release notes file, which itself is ReStructuredText. For example, the .. feature:: directive would map to a New Features section.
Release note directives can be either short-form or long-form. In short- form, title is omitted and the release note is rendered as a bullet list. In long form, a sub-section with the title title is added to the section.
The FILE argument controls the output file to write gathered release notes to. The format of the file is:
Section 1 =========
Section 2 =========
Only sections with defined release notes are emitted.
If a section only has short-form notes, it will consist of bullet list:
Section =======
* Release note 1 * Release note 2
If a section has long-form notes, sub-sections will be emitted:
Note 1 Title ------------
Description of the first long-form note.
Note 2 Title ------------
Description of the second long-form note.
If the FILE argument points to an existing file, that file will be parsed for release notes having the format that would be generated by this command. The notes from the processed commit messages will be merged into this parsed set.
During release notes merging:
• Duplicate items are automatically ignored
• Items that are different are automatically ignored if the similarity is greater than a threshold.
This means that the release notes file can be updated independently from this command and changes should not be lost when running this command on that file. A particular use case for this is to tweak the wording of a release note after it has been added to the release notes file.
The -c/--check option checks the commit message for invalid admonitions.
The -l/--list option, presents the user with a list of existing available admonitions along with their title. This also includes the custom admonitions (if any).
-r,--rev <REV> revisions to process for release notes
-c, --check checks for validity of admonitions (if any)
-l, --list list the available admonitions with their title
Uncategorized commands relink recreates hardlinks between repository clones
Commands Repository maintenance relink recreate hardlinks between two repositories:
hg relink [ORIGIN]
When repositories are cloned locally, their data files will be hardlinked so that they only use the space of a single repository.
Unfortunately, subsequent pulls into either repository will break hardlinks for any files touched by the new changesets, even if both repositories end up pulling the same changes.
Similarly, passing --rev to "hg clone" will fail to use any hardlinks, falling back to a complete copy of the source repository.
This command lets you recreate those hardlinks and reclaim that wasted space.
This repository will be relinked to share space with ORIGIN, which must be on the same local disk. If ORIGIN is omitted, looks for "default-relink", then "default", in [paths].
Do not attempt any read operations on this repository while the command is running. (Both repositories will be locked against writes.)
remotefilelog remotefilelog causes Mercurial to lazilly fetch file contents (EXPERIMENTAL)
This extension is HIGHLY EXPERIMENTAL. There are NO BACKWARDS COMPATIBILITY GUARANTEES. This means that repositories created with this extension may only be usable with the exact version of this extension/Mercurial that was used. The extension attempts to enforce this in order to prevent repository corruption.
remotefilelog works by fetching file contents lazily and storing them in a cache on the client rather than in revlogs. This allows enormous histories to be transferred only partially, making them easier to operate on.
packs.maxchainlen specifies the maximum delta chain length in pack files
packs.maxpacksize specifies the maximum pack file size
packs.maxpackfilecount specifies the maximum number of packs in the
shared cache (trees only for now)
remotefilelog.backgroundprefetch runs prefetch in background when True
remotefilelog.bgprefetchrevs specifies revisions to fetch on commit and
update, and on other commands that use them. Different from pullprefetch.
remotefilelog.gcrepack does garbage collection during repack when True
remotefilelog.nodettl specifies maximum TTL of a node in seconds before
it is garbage collected
remotefilelog.repackonhggc runs repack on hg gc when True
remotefilelog.prefetchdays specifies the maximum age of a commit in
days after which it is no longer prefetched.
remotefilelog.prefetchdelay specifies delay between background
prefetches in seconds after operations that change the working copy parent
remotefilelog.data.gencountlimit constraints the minimum number of data
pack files required to be considered part of a generation. In particular, minimum number of packs files > gencountlimit.
remotefilelog.data.generations list for specifying the lower bound of
each generation of the data pack files. For example, list ['100MB','1MB'] or ['1MB', '100MB'] will lead to three generations: [0, 1MB), [ 1MB, 100MB) and [100MB, infinity).
remotefilelog.data.maxrepackpacks the maximum number of pack files to
include in an incremental data repack.
remotefilelog.data.repackmaxpacksize the maximum size of a pack file for
it to be considered for an incremental data repack.
remotefilelog.data.repacksizelimit the maximum total size of pack files
to include in an incremental data repack.
remotefilelog.history.gencountlimit constraints the minimum number of
history pack files required to be considered part of a generation. In particular, minimum number of packs files > gencountlimit.
remotefilelog.history.generations list for specifying the lower bound of
each generation of the history pack files. For example, list [ '100MB', '1MB'] or ['1MB', '100MB'] will lead to three generations: [ 0, 1MB), [1MB, 100MB) and [100MB, infinity).
remotefilelog.history.maxrepackpacks the maximum number of pack files to
include in an incremental history repack.
remotefilelog.history.repackmaxpacksize the maximum size of a pack file
for it to be considered for an incremental history repack.
remotefilelog.history.repacksizelimit the maximum total size of pack
files to include in an incremental history repack.
remotefilelog.backgroundrepack automatically consolidate packs in the
remotefilelog.cachepath path to cache
remotefilelog.cachegroup if set, make cache directory sgid to this
remotefilelog.cacheprocess binary to invoke for fetching file data
remotefilelog.debug turn on remotefilelog-specific debug output
remotefilelog.excludepattern pattern of files to exclude from pulls
remotefilelog.includepattern pattern of files to include in pulls
remotefilelog.fetchwarning: message to print when too many
single-file fetches occur
remotefilelog.getfilesstep number of files to request in a single RPC
remotefilelog.getfilestype if set to 'threaded' use threads to fetch
files, otherwise use optimistic fetching
remotefilelog.pullprefetch revset for selecting files that should be
eagerly downloaded rather than lazily
remotefilelog.reponame name of the repo. If set, used to partition
data from other repos in a shared store.
remotefilelog.server if true, enable server-side functionality
remotefilelog.servercachepath path for caching blobs on the server
remotefilelog.serverexpiration number of days to keep cached server
remotefilelog.validatecache if set, check cache entries for corruption
before returning blobs
remotefilelog.validatecachelog if set, check cache entries for
corruption before returning metadata
Commands Repository maintenance prefetch prefetch file revisions from the server:
hg prefetch [OPTIONS] [FILE...]
Prefetchs file revisions for the specified revs and stores them in the local remotefilelog cache.  If no rev is specified, the default rev is used which is the union of dot, draft, pullprefetch and bgprefetchrev. File names or patterns can be used to limit which files are downloaded.
-r,--rev <REV[+]> prefetch the specified revisions
--repack run repack after prefetch
-b,--base <VALUE> rev that is assumed to already be local
Uncategorized commands gc garbage collect the client and server filelog caches:
hg gc [REPO...]
garbage collect the client and server filelog caches
repack hg repack [OPTIONS]
--background run in a background process
--incremental do an incremental repack
--packsonly only repack packs (skip loose objects)
verifyremotefilelog hg verifyremotefilelogs <directory>
-d, --decompress decompress the filelogs first
remotenames showing remotebookmarks and remotebranches in UI (EXPERIMENTAL)
By default both remotebookmarks and remotebranches are turned on. Config knob to control the individually are as follows.
Config options to tweak the default behaviour:
remotenames.bookmarks Boolean value to enable or disable showing of remotebookmarks (default: True)
remotenames.branches Boolean value to enable or disable showing of remotebranches (default: True)
remotenames.hoistedpeer Name of the peer whose remotebookmarks should be hoisted into the top-level namespace (default: 'default')
This extension allows you to specify shortcuts for parent URLs with a lot of repositories to act like a scheme, for example:
[schemes] py = http://code.python.org/hg/
After that you can use it like:
hg clone py://trunk/
Additionally there is support for some more complex schemas, for example used by Google Code:
[schemes] gcode = http://{1}.googlecode.com/hg/
The syntax is taken from Mercurial templates, and you have unlimited number of variables, starting with {1} and continuing with {2}, {3} and so on. This variables will receive parts of URL supplied, split by /. Anything not specified as {part} will be just appended to an URL.
For convenience, the extension adds these schemes by default:
[schemes] py = http://hg.python.org/ bb = https://bitbucket.org/ bb+ssh = ssh://hg@bitbucket.org/ gcode = https://{1}.googlecode.com/hg/ kiln = https://{1}.kilnhg.com/Repo/
You can override a predefined scheme by defining a new scheme with the same name.
Commands Uncategorized commands share share a common history between several working directories
The share extension introduces a new command hg share to create a new working directory. This is similar to hg clone, but doesn't involve copying or linking the storage of the repository. This allows working on different branches or changes in parallel without the associated cost in terms of disk space.
Note: destructive operations or extensions like hg rollback should be used with care as they can result in confusing problems.
Automatic Pooled Storage for Clones When this extension is active, hg clone can be configured to automatically share/pool storage across multiple clones. This mode effectively converts hg clone to hg clone + hg share.  The benefit of using this mode is the automatic management of store paths and intelligent pooling of related repositories.
The following share. config options influence this feature:
share.pool
Filesystem path where shared repository data will be stored. When defined, hg clone will automatically use shared repository storage instead of creating a store inside each clone.
share.poolnaming
How directory names in share.pool are constructed.
"identity" means the name is derived from the first changeset in the repository. In this mode, different remotes share storage if their root/initial changeset is identical. In this mode, the local shared repository is an aggregate of all encountered remote repositories.
"remote" means the name is derived from the source repository's path or URL. In this mode, storage is only shared if the path or URL requested in the hg clone command matches exactly to a repository that was cloned before.
The default naming mode is "identity".
Sharing requirements and configs of source repository with shares:
By default creating a shared repository only enables sharing a common history and does not share requirements and configs between them. This may lead to problems in some cases, for example when you upgrade the storage format from one repository but does not set related configs in the shares.
Setting format.exp-share-safe = True enables sharing configs and requirements. This only applies to shares which are done after enabling the config option.
For enabling this in existing shares, enable the config option and reshare.
For resharing existing shares, make sure your working directory is clean and there are no untracked files, delete that share and create a new share.
Commands Repository creation share create a new shared repository:
hg share [-U] [-B] SOURCE [DEST]
Initialize a new repository and working directory that shares its history (and optionally bookmarks) with another repository.
Note   using rollback or extensions that destroy/modify history (mq, rebase, etc.) can cause considerable confusion with shared clones. In particular, if two shared clones are both updated to the same changeset, and one of them destroys that changeset with rollback, the other clone will suddenly stop working: all operations will fail with "abort: working directory has unknown parent". The only known workaround is to use debugsetparents on the broken clone to reset it to a changeset that still exists.
-U, --noupdate do not create a working directory
-B, --bookmarks also share bookmarks
--relative point to source using a relative path
Repository maintenance unshare convert a shared repository to a normal one:
hg unshare
Copy the store data to the repo and remove the sharedpath data.
show unified command to show various repository information (EXPERIMENTAL)
This extension provides the hg show command, which provides a central command for displaying commonly-accessed repository data and views of that data.
The following config options can influence operation.
commands show.aliasprefix
List of strings that will register aliases for views. e.g. s will effectively set config options alias.s<view> = show <view> for all views. i.e. hg swork would execute hg show work.
Aliases that would conflict with existing registrations will not be performed.
Commands Change navigation show show various repository information:
hg show VIEW
A requested view of repository data is displayed.
If no view is requested, the list of available views is shown and the command aborts.
Note   There are no backwards compatibility guarantees for the output of this command. Output may change in any future Mercurial release.
Consumers wanting stable command output should specify a template via -T/--template.
List of available views:
bookmarks   bookmarks and their associated changeset
stack       current line of work
work        changesets that aren't finished
sparse allow sparse checkouts of the working directory (EXPERIMENTAL)
(This extension is not yet protected by backwards compatibility guarantees. Any aspect may break in future releases until this notice is removed.)
This extension allows the working directory to only consist of a subset of files for the revision. This allows specific files or directories to be explicitly included or excluded. Many repository operations have performance proportional to the number of files in the working directory. So only realizing a subset of files in the working directory can improve performance.
Sparse Config Files The set of files that are part of a sparse checkout are defined by a sparse config file. The file defines 3 things: includes (files to include in the sparse checkout), excludes (files to exclude from the sparse checkout), and profiles (links to other config files).
The file format is newline delimited. Empty lines and lines beginning with # are ignored.
Lines beginning with %include `` denote another sparse config file to include. e.g. ``%include tests.sparse. The filename is relative to the repository root.
The special lines [include] and [exclude] denote the section for includes and excludes that follow, respectively. It is illegal to have [include] after [exclude].
Non-special lines resemble file patterns to be added to either includes or excludes. The syntax of these lines is documented by hg help patterns. Patterns are interpreted as glob: by default and match against the root of the repository.
Exclusion patterns take precedence over inclusion patterns. So even if a file is explicitly included, an [exclude] entry can remove it.
For example, say you have a repository with 3 directories, frontend/, backend/, and tools/. frontend/ and backend/ correspond to different projects and it is uncommon for someone working on one to need the files for the other. But tools/ contains files shared between both projects. Your sparse config files may resemble:
# frontend.sparse frontend/** tools/**
# backend.sparse backend/** tools/**
Say the backend grows in size. Or there's a directory with thousands of files you wish to exclude. You can modify the profile to exclude certain files:
[include] backend/** tools/**
[exclude] tools/tests/**
Commands Uncategorized commands split command to split a changeset into smaller ones (EXPERIMENTAL)
Commands Change manipulation split split a changeset into smaller ones:
hg split [--no-rebase] [[-r] REV]
Repeatedly prompt changes and commit message for new changesets until there is nothing left in the original changeset.
If --rev was not given, split the working directory parent.
By default, rebase connected non-obsoleted descendants onto the new changeset. Use --no-rebase to avoid the rebase.
-r,--rev <REV> revision to split
--rebase rebase descendants after split (default: True)
sqlitestore store repository data in SQLite (EXPERIMENTAL)
The sqlitestore extension enables the storage of repository data in SQLite.
In addition, several features are not yet supported or have known bugs:
• Only some data is stored in SQLite. Changeset, manifest, and other repository data is not yet stored in SQLite.
• Transactions are not robust. If the process is aborted at the right time during transaction close/rollback, the repository could be in an inconsistent state. This problem will diminish once all repository data is tracked by SQLite.
• Bundle repositories do not work (the ability to use e.g.  hg -R <bundle-file> log to automatically overlay a bundle on top of the existing repository).
• Various other features don't work.
This extension should work for basic clone/pull, update, and commit workflows.  Some history rewriting operations may fail due to lack of support for bundle repositories.
To use, activate the extension and set the storage.new-repo-backend config option to sqlite to enable new repositories to use SQLite for storage.
strip strip changesets and their descendants from history (DEPRECATED)
The functionality of this extension has been included in core Mercurial since version 5.7. Please use hg debugstrip ... instead.
This extension allows you to strip changesets and all their descendants from the repository. See the command help for details.
This extension allows you to transplant changes to another parent revision, possibly in another repository. The transplant is done using 'diff' patches.
Transplanted patches are recorded in .hg/transplant/transplants, as a map from a changeset hash to its hash in the source repository.
Commands Change manipulation transplant transplant changesets from another branch:
hg transplant [-s REPO] [-b BRANCH [-a]] [-p REV] [-m REV] [REV]...
Selected changesets will be applied on top of the current working directory with the log of the original changeset. The changesets are copied and will thus appear twice in the history with different identities.
Consider using the graft command if everything is inside the same repository - it will use merges and will usually give a better result. Use the rebase extension if the changesets are unpublished and you want to move them instead of copying them.
(transplanted from CHANGESETHASH)
You can rewrite the changelog message with the --filter option.  Its argument will be invoked with the current changelog message as $1 and the patch as $2.
--source/-s specifies another repository to use for selecting changesets, just as if it temporarily had been pulled.  If --branch/-b is specified, these revisions will be used as heads when deciding which changesets to transplant, just as if only these revisions had been pulled.  If --all/-a is specified, all the revisions up to the heads specified with --branch will be transplanted.
• transplant all changes up to REV on top of your current revision:
hg transplant --branch REV --all
You can optionally mark selected transplanted changesets as merge changesets. You will not be prompted to transplant any ancestors of a merged transplant, and you can merge descendants of them normally instead of transplanting them.
Merge changesets may be transplanted directly by specifying the proper parent changeset by calling hg transplant --parent.
If no merges or revisions are provided, hg transplant will start an interactive changeset browser.
If a changeset application fails, you can fix the merge by hand and then resume where you left off by calling hg transplant --continue/-c.
-s,--source <REPO> transplant changesets from REPO
-b,--branch <REV[+]> use this source changeset as head
-a, --all pull all changesets up to the --branch revisions
-p,--prune <REV[+]> skip over REV
-m,--merge <REV[+]> merge at REV
--parent <REV> parent to choose when transplanting merge
--log  append transplant info to log message
--stop stop interrupted transplant
-c, --continue continue last transplant session after fixing conflicts
--filter <CMD> filter changesets through command
uncommit uncommit part or all of a local changeset (EXPERIMENTAL)
This command undoes the effect of a local commit, returning the affected files to their uncommitted state. This means that files modified, added or removed in the changeset will be left unchanged, and so will remain modified, added and removed in the working directory.
Commands Change manipulation unamend undo the most recent amend operation on a current changeset:
hg unamend
This command will roll back to the previous version of a changeset, leaving working directory in state in which it was before running hg amend (e.g. files modified as part of an amend will be marked as modified hg status)
uncommit uncommit part or all of a local changeset:
hg uncommit [OPTION]... [FILE]...
This command undoes the effect of a local commit, returning the affected files to their uncommitted state. This means that files modified or deleted in the changeset will be left unchanged, and so will remain modified in the working directory.
If no files are specified, the commit will be pruned, unless --keep is given.
--keep allow an empty commit after uncommitting
--allow-dirty-working-copy allow uncommit with outstanding changes
-n,--note <TEXT> store a note on uncommit
Some MBCS encodings are not good for some path operations (i.e. splitting path, case conversion, etc.) with its encoded bytes. We call such a encoding (i.e. shift_jis and big5) as "problematic encoding". This extension can be used to fix the issue with those encodings by wrapping some functions to convert to Unicode string before path operation.
This extension is useful for:
• Japanese Windows users using shift_jis encoding.
• Chinese Windows users using big5 encoding.
• All users who use a repository with one of problematic encodings on case-insensitive file system.
This extension is not needed for:
• Any user who use only ASCII chars in path.
• Any user who do not use any of problematic encodings.
Note that there are some limitations on using this extension:
• You should use single encoding in one repository.
• If the repository path ends with 0x5c, .hg/hgrc cannot be read.
• win32mbcs is not compatible with fixutf8 extension.
By default, win32mbcs uses encoding.encoding decided by Mercurial.  You can specify the encoding by config option:
[win32mbcs] encoding = sjis
It is useful for the users who want to commit with UTF-8 log message.
win32text perform automatic newline conversion (DEPRECATED)
Deprecation: The win32text extension requires each user to configure the extension again and again for each clone since the configuration is not copied when cloning.
We have therefore made the eol as an alternative. The eol uses a version controlled file for its configuration and each clone will therefore use the right settings from the start.
To perform automatic newline conversion, use:
[extensions] win32text = [encode] ** = cleverencode: # or ** = macencode:
[decode] ** = cleverdecode: # or ** = macdecode:
If not doing conversion, to make sure you do not commit CRLF/CR by accident:
[hooks] pretxncommit.crlf = python:hgext.win32text.forbidcrlf # or pretxncommit.cr = python:hgext.win32text.forbidcr
To do the same check on a server to prevent CRLF/CR from being pushed or pulled:
[hooks] pretxnchangegroup.crlf = python:hgext.win32text.forbidcrlf # or pretxnchangegroup.cr = python:hgext.win32text.forbidcr
The zeroconf extension will advertise hg serve instances over DNS-SD so that they can be discovered using the hg paths command without knowing the server's IP address.
To allow other people to discover your repository using run hg serve in your repository:
$ cd test $ hg serve
You can discover Zeroconf-enabled repositories by running hg paths:
$ hg paths zc-test = http://example.com:8000/test
/etc/mercurial/hgrc, $HOME/.hgrc, .hg/hgrc
This file contains defaults and configuration. Values in .hg/hgrc override those in $HOME/.hgrc, and these override settings made in the global /etc/mercurial/hgrc configuration.  See hgrc(5) for details of the contents and format of these files.
This file contains regular expressions (one per line) that describe file names that should be ignored by hg. For details, see hgignore(5).
.hgsub
This file defines the locations of all subrepositories, and tells where the subrepository checkouts came from. For details, see hg help subrepos.
.hgsubstate
This file is where Mercurial stores all nested repository states. NB: This file should not be edited manually.
.hgtags
This file contains changeset hash values and text tag names (one of each separated by spaces) that correspond to tagged versions of the repository contents. The file content is encoded using UTF-8.
.hg/last-message.txt
This file is used by hg commit to store a backup of the commit message in case the commit fails.
.hg/localtags
This file can be used to define local tags which are not shared among repositories. The file format is the same as for .hgtags, but it is encoded using the local system encoding.
Some commands (e.g. revert) produce backup files ending in .orig, if the .orig file already exists and is not tracked by Mercurial, it will be overwritten.
Probably lots, please post them to the mailing list (see Resources below) when you find them.
hgignore(5), hgrc(5)
Written by Olivia Mackall <olivia@selenic.com>
Olivia Mackall <olivia@selenic.com>
Organization: Mercurial
Main Web Site: https://mercurial-scm.org/
Source code repository: https://www.mercurial-scm.org/repo/hg
Mailing list: https://www.mercurial-scm.org/mailman/listinfo/mercurial/
Copyright (C) 2005-2021 Olivia Mackall.  Free use of this software is granted under the terms of the GNU General Public License version 2 or any later version.
UNIMPLEMENTED(2)            Linux Programmer's Manual           UNIMPLEMENTED(2)
afs_syscall, break, fattach, fdetach, ftime, getmsg, getpmsg, gtty, isastream, lock, madvise1, mpx, prof, profil, putmsg, putpmsg, security, stty, tuxcall, ulimit, vserver - unimplemented system calls
Unimplemented system calls.
These system calls are not implemented in the Linux kernel.
These system calls always return -1 and set errno to ENOSYS.
Note that ftime(3), profil(3), and ulimit(3) are implemented as library functions.
Some system calls, like alloc_hugepages(2), free_hugepages(2), ioperm(2), iopl(2), and vm86(2) exist only on certain architectures.
Some system calls, like ipc(2), create_module(2), init_module(2), and delete_module(2) exist only when the Linux kernel was built with support for them.
syscalls(2)
GO-ENV(1)                    General Commands Manual                   GO-ENV(1)
go-env - print Go environment information
go env [ var ...  ]
Env prints Go environment information.
By default env prints information as a shell script (on Windows, a batch file). If one or more variable names is given as arguments, env prints the value of each named variable on its own line.
-json  prints the environment in JSON format instead of as a shell script.
-u     requires one or more arguments and unsets the default setting for the named environment variables, if one has been set with 'go env -w'.
-w     requires one or more arguments of the form NAME=VALUE and changes the default settings of the named environment variables to the given values.
For more about environment variables, see 'go help environment'.
This manual page was written by Michael Stapelberg <stapelberg@debian.org> and is maintained by the Debian Go Compiler Team <team+go-compiler@tracker.debian.org> based on the output of 'go help env' for the Debian project (and may be used by others).
KJS::HashEntry(3)           Library Functions Manual           KJS::HashEntry(3)
KJS::HashEntry - An entry in a hash table.
#include <lookup.h>
Public Attributes const  char * s s is the key (e.g. int value value is the result value (usually an enum value) short int attr attr is a set for flags (e.g. short int params params is another number. const  HashEntry * next next is the pointer to the next entry for the same hash value
Detailed Description An entry in a hash table. Definition at line 37 of file lookup.h.
Member Data Documentation const char* KJS::HashEntry::s s is the key (e.g. a property name) Definition at line 41 of file lookup.h.
int KJS::HashEntry::value value is the result value (usually an enum value) Definition at line 45 of file lookup.h.
short int KJS::HashEntry::attr attr is a set for flags (e.g. the property flags, see object.h) Definition at line 49 of file lookup.h.
short int KJS::HashEntry::params params is another number. For property hashtables, it is used to denote the number of argument of the function Definition at line 54 of file lookup.h.
const HashEntry* KJS::HashEntry::next next is the pointer to the next entry for the same hash value Definition at line 58 of file lookup.h.
Author Generated automatically by Doxygen for kjs Library from the source code.
GXL2GV,GV2GXL(1)             General Commands Manual            GXL2GV,GV2GXL(1)
gxl2gv,gv2gxl - GXL-GV converters
gxl2gv [ -gd?  ] [ -ooutfile ] [ files ] gv2gxl [ -gd?  ] [ -ooutfile ] [ files ]
gxl2gv converts between graphs represented in GXL and in the GV language. Unless a conversion type is specified using a flag, gxl2gv will deduce the type of conversion from the suffix of the input file, a ".gv" suffix causing a conversion from GV to GXL, and a ".gxl" suffix causing a conversion from GXL to GV.  If no suffix is available, e.g. when the input is from a pipe, and no flags are used then gxl2gv assumes the type of the input file from its executable name so that gxl2gv converts from GXL to GV, and gv2gxl converts from GV to GXL.
GXL supports a much richer graph model than GV. gxl2gv will attempt to map GXL constructs into the analogous GV construct when this is possible. If not, the GXL information is stored as an attribute. The intention is that applying gxl2gv|gv2gxl is semantically equivalent to the identity operator.
-g     The command name and input file extensions are ignored, the input is taken as a GV file and a GXL file is generated.
-d     The command name and input file extensions are ignored, the input is taken as a GXL file and a GV file is generated.
-?     Prints usage information and exits.
-o outfile If specified, the output will be written into the file outfile. Otherwise, output is written to standard out.
files   Names of files containing 1 or more graphs in GXL or GV.  If no files operand is specified, the standard input will be used.
Both gxl2gv and gv2gxl return 0 if there were no problems during conversion; and non-zero if any error occurred.
gxl2gv will only convert in one direction even if given multiple files with varying suffixes.
The conversion can only handle one graph per GXL file.
There are some GXL constructs which gxl2gv cannot handle.
Krishnam Pericherla <kp@research.att.com> Emden R. Gansner <erg@research.att.com>
dot(1), neato(1), twopi(1)
GOOGLE(1)                         User Commands                        GOOGLE(1)
google - command-line access to (some) Google services
google [help|picasa|blogger|youtube|docs|contacts|calendar|finance] TASK [options]
This program provides command-line access to (some) google services via their gdata APIs.  Called without a service name, it starts an interactive session.
NOTE: GoogleCL will interpret arguments as required options in the order they appear in the descriptions below, excluding options set in the configuration file and non-primary terms in parenthesized OR groups. For example:
$ google picasa get my_album .
is interpreted as "google picasa get --title=my_album --dest=.
$ google contacts list john
is interpreted as "$ google contacts list --fields=<config file def> --title=john --delimiter=," (only true if you have not removed the default definition in the config file!)
$ google docs get my_doc .
is interpreted as "$ google docs get --title=my_doc --dest=.  (folder is NOT set, since the title option is satisfied first.)
Available tasks for service picasa: 'get', 'create', 'list', 'list-albums', 'tag', 'post', 'delete'
get: Download albums
Requires: title AND dest Optional: owner, format, photo
create: Create an album
Requires: title Optional: src, date, summary, tags, access
list: List photos
Requires: fields AND delimiter Optional: title, query, owner, photo
list-albums: List albums
Requires: fields AND delimiter Optional: title, owner
tag: Tag/caption photos
Requires: (title OR query) AND (tags OR summary) Optional: owner, photo
post: Post photos to an album
Requires: title AND src Optional: tags, owner, photo, summary
delete: Delete photos or albums
Requires: (title OR query) Optional: photo
Available tasks for service blogger: 'post', 'tag', 'list', 'delete'
post: Post content.
Requires: src AND blog Optional: title, tags, access
tag: Label posts
Requires: blog AND title AND tags
list: List posts in a blog
Requires: fields AND blog AND delimiter Optional: title, owner
delete: Delete a post.
Requires: blog AND title
Available tasks for service youtube: 'post', 'tag', 'list', 'delete'
post: Post a video.
Requires: src AND category AND devkey Optional: title, summary, tags, access
tag: Add tags to a video and/or change its category.
Requires: title AND (tags OR category) AND devkey
list: List videos by user.
delete: Delete videos.
Requires: title AND devkey
Available tasks for service docs: 'edit', 'delete', 'list', 'upload', 'get'
edit: Edit a document
Requires: title Optional: format, editor, folder
delete: Delete documents
Requires: title Optional: folder
list: List documents
Requires: fields AND delimiter Optional: title, folder
upload: Upload a document
Requires: src Optional: title, folder, format
get: Download a document
Requires: (title OR folder) AND dest Optional: format
Available tasks for service contacts: 'list', 'list-groups', 'add', 'add-groups', 'delete-groups', 'delete'
list: List contacts
Requires: fields AND title AND delimiter
list-groups: List contact groups
Requires: title
add: Add contacts
Requires: src
add-groups: Add contact group(s)
delete-groups: Delete contact group(s)
delete: Delete contacts
Available tasks for service calendar: 'add', 'list', 'today', 'delete'
add: Add event to a calendar
Requires: src Optional: cal
list: List events on a calendar
Requires: fields AND delimiter Optional: title, query, date, cal
today: List events for the next 24 hours
Requires: fields AND delimiter Optional: title, query, cal
delete: Delete event from a calendar
Requires: (title OR query) Optional: date, cal
Available tasks for service finance: 'list-txn', 'delete-pos', 'create-pos', 'delete-txn', 'create', 'create-txn', 'list', 'list-pos', 'delete'
list-txn: List transactions
Requires: title AND ticker
delete-pos: Delete positions
Requires: title Optional: ticker
create-pos: Create position
delete-txn: Delete transactions
Requires: title AND ticker Optional: txnid
create: Create a portfolio
Requires: title AND currency
create-txn: Create transaction
Requires: title AND ticker AND ttype AND shares AND price Optional: shares, price, date, commission, currency, notes
list: List portfolios
Requires: none Optional: fields
list-pos: List positions
Requires: title Optional: fields
delete: Delete portfolios
--access=ACCESS Specify access/visibility level of an upload
--blog=BLOG Blogger only - specify a blog other than your primary.
--cal=CAL Calendar only - specify a calendar other than your primary.
-c CATEGORY, --category=CATEGORY YouTube only - specify video categories as a commaseparated list, e.g. "Film, Travel"
--commission=COMMISSION Finance only - specify commission for transaction
--config=CONFIG Specify location of config file.
--currency=CURRENCY Finance only - specify currency for portfolio
--devtags=DEVTAGS YouTube only - specify developer tags as a commaseparated list.
--devkey=DEVKEY YouTube only - specify a developer key
-d DATE, --date=DATE Calendar only - date of the event to add/look for. Can also specify a range with a comma. Picasa only - sets the date of the album Finance only - transaction creation date
--debug Enable all debugging output, including HTTP data
--delimiter=DELIMITER Specify a delimiter for the output of the list task.
--dest=DEST Destination. Typically, where to save data being downloaded.
--draft Blogger only - post as a draft. Shorthand for --access=draft
--editor=EDITOR Docs only - editor to use on a file.
--fields=FIELDS Fields to list with list task.
-f FOLDER, --folder=FOLDER Docs only - specify folder(s) to upload to / search in.
--force-auth Force validation step for re-used access tokens (Overrides --skip-auth).
--format=FORMAT Docs only - format to download documents as.
--hostid=HOSTID Label the machine being used.
-n TITLE, --title=TITLE Title of the item
--no-convert Google Apps Premier only - do not convert the file on upload. (Else converts to native Google Docs format)
--notes=NOTES Finance only - specify notes for transaction
-o OWNER, --owner=OWNER Username or ID of the owner of the resource. For example, 'picasa list-albums -o bob' to list bob's albums
--photo=PHOTO Picasa only - specify title or name of photo(s)
--price=PRICE Finance only - specify price for transaction
-q QUERY, --query=QUERY Full text query string for specifying items. Searches on titles, captions, and tags.
--quiet Print only prompts and error messages
--reminder=REMINDER Calendar only - specify time for added event's reminder, e.g. "10m", "3h", "1d"
--shares=SHARES Finance only - specify amount of shares for transaction
--skip-auth Skip validation step for re-used access tokens.
--src=SRC Source. Typically files to upload.
-s SUMMARY, --summary=SUMMARY Description of the upload, or file containing the description.
-t TAGS, --tags=TAGS Tags for item, e.g. "Sunsets, Earth Day"
--ticker=TICKER Finance only - specify ticker
--ttype=TTYPE Finance only - specify transaction type, e.g. "Bye", "Sell", "Buy to Cover", "Sell Short"
--txnid=TXNID Finance only - specify transaction id
-u USER, --user=USER Username to log in with for the service. If not provided full email address (e.g. "foo"), than it is assumed to be in gmail.com domain (e.g.  "foo@gmail.com"). If you want to use another domain, provide full email address like "foo@bar.com"
-v, --verbose Print all messages.
--yes  Answer "yes" to all prompts
google blogger post --title 'foo' 'command line posting'
google calendar add 'Lunch with Jim at noon tomorrow'
google contacts list --title '.*' --fields name,email,phone > contacts.csv
google docs edit --title 'Shopping list'
google picasa create --title 'Cat Photos' ~/photos/cats/*.jpg
google youtube post --category Education killer_robots.avi
ZSH(1)                       General Commands Manual                      ZSH(1)
zsh - the Z shell
Because zsh contains many features, the zsh manual has been split into a number of sections:
zsh          Zsh overview (this section) zshroadmap   Informal introduction to the manual zshmisc      Anything not fitting into the other sections zshexpn      Zsh command and parameter expansion zshparam     Zsh parameters zshoptions   Zsh options zshbuiltins  Zsh built-in functions zshzle       Zsh command line editing zshcompwid   Zsh completion widgets zshcompsys   Zsh completion system zshcompctl   Zsh completion control zshmodules   Zsh loadable modules zshcalsys    Zsh built-in calendar functions zshtcpsys    Zsh built-in TCP functions zshzftpsys   Zsh built-in FTP client zshcontrib   Additional zsh functions and utilities zshall       Meta-man page containing all of the above
Zsh is a UNIX command interpreter (shell) usable as an interactive login shell and as a shell script command processor.  Of the standard shells, zsh most closely resembles ksh but includes many enhancements.  It does not provide compatibility with POSIX or other shells in its default operating mode:  see the section Compatibility below.
Zsh has command line editing, builtin spelling correction, programmable command completion, shell functions (with autoloading), a history mechanism, and a host of other features.
Zsh was originally written by Paul Falstad <pf@zsh.org>.  Zsh is now maintained by the members of the zsh-workers mailing list <zsh-workers@zsh.org>.  The development is currently coordinated by Peter Stephenson <pws@zsh.org>.  The coordinator can be contacted at <coordinator@zsh.org>, but matters relating to the code should generally go to the mailing list.
Zsh is available from the following HTTP and anonymous FTP site.
ftp://ftp.zsh.org/pub/ https://www.zsh.org/pub/ )
The up-to-date source code is available via Git from Sourceforge.  See https://sourceforge.net/projects/zsh/ for details.  A summary of instructions for the archive can be found at http://zsh.sourceforge.net/.
Zsh has 3 mailing lists:
<zsh-announce@zsh.org> Announcements about releases, major changes in the shell and the monthly posting of the Zsh FAQ.  (moderated)
<zsh-users@zsh.org> User discussions.
<zsh-workers@zsh.org> Hacking, development, bug reports and patches.
To subscribe or unsubscribe, send mail to the associated administrative address for the mailing list.