neulab/tldr huggingface dataset:
remote.<name>.annex-shell Specify an alternative git-annex-shell executable on the remote instead of looking for "git-annex-shell" on the PATH.
This is useful if the git-annex-shell program is outside the PATH or has a non-standard name.
remote.<name>.annex-ignore If set to true, prevents git-annex from storing file contents on this remote by default.  (You can still request it be used by the --from and --to options.)
This is, for example, useful if the remote is located somewhere without git-annex-shell. (For example, if it's on GitHub).  Or, it could be used if the network connection between two repositories is too slow to be used normally.
This does not prevent git-annex sync (or the git-annex assistant) from syncing the git repository to the remote.
remote.<name>.annex-ignore-command If set, the command is run, and if it exits nonzero, that's the same as setting annex-ignore to true. This allows controlling behavior based on e.g., the current network.
remote.<name>.annex-sync If set to false, prevents git-annex sync (and the git-annex assistant) from syncing with this remote by default. However, git annex sync <name> can still be used to sync with the remote.
remote.<name>.annex-sync-command If set, the command is run, and if it exits nonzero, that's the same as setting annex-sync to false. This allows controlling behavior based on e.g., the current network.
remote.<name>.annex-pull If set to false, prevents git-annex sync (and the git-annex assistant etc) from ever pulling (or fetching) from the remote.
remote.<name>.annex-push If set to false, prevents git-annex sync (and the git-annex assistant etc) from ever pushing to the remote.
remote.<name>.annex-readonly If set to true, prevents git-annex from making changes to a remote.  This both prevents git-annex sync from pushing changes, and prevents storing or removing files from read-only remote.
remote.<name>.annex-verify, annex.verify By default, git-annex will verify the checksums of objects downloaded from remotes. If you trust a remote and don't want the overhead of these checksums, you can set this to false.
Note that even when this is set to false, git-annex does verification in some edge cases, where it's likely the case than an object was downloaded incorrectly, or when needed for security.
remote.<name>.annex-tracking-branch This is for use with special remotes that support exports and imports.
When set to eg, "master", this tells git-annex that you want the special remote to track that branch.
When set to eg, "master:subdir", the special remote tracks only the subdirectory of that branch.
git-annex sync --content will import changes from the remote and merge them into the annex-tracking-branch. They also export changes made to the branch to the remote.
remote.<name>.annex-export-tracking Deprecated name for remote.<name>.annex-tracking-branch. Will still be used if it's configured and remote.<name>.annex-tracking-branch is not.
remote.<name>.annexUrl Can be used to specify a different url than the regular remote.<name>.url for git-annex to use when talking with the remote. Similar to the pushUrl used by git-push.
remote.<name>.annex-uuid git-annex caches UUIDs of remote repositories here.
remote.<name>.annex-config-uuid Used for some special remotes, points to a different special remote configuration to use.
remote.<name>.annex-retry, annex.retry Number of times a transfer that fails can be retried. (default 0)
remote.<name>.annex-forward-retry, annex.forward-retry If a transfer made some forward progress before failing, this allows it to be retried even when annex.retry does not.  The value is the maximum number of times to do that. (default 5)
When both annex.retry and this are set, the maximum number of retries is the larger of the two.
remote.<name>.annex-retry-delay, annex.retry-delay Number of seconds to delay before the first retry of a transfer. When making multiple retries of the same transfer, the delay doubles after each retry. (default 1)
remote.<name>.annex-stalldetecton, annex.stalldetection Configuring this lets stalled or too-slow transfers be detected, and dealt with, so rather than getting stuck, git-annex will cancel the stalled operation. The transfer will be considered to have failed, so settings like annex.retry will control what it does next.
By default, git-annex detects transfers that have probably stalled, and suggests configuring this. If it is incorrectly detecting stalls, setting this to "false" will avoid that.
Set to "true" to enable automatic stall detection. If a remote does not update its progress consistently, no automatic stall detection will be done. And it may take a while for git-annex to decide a remote is really stalled when using automatic stall detection, since it needs to be conservative about what looks like a stall.
For more fine control over what constitutes a stall, set to a value in the form "$amount/$timeperiod" to specify how much data git-annex should expect to see flowing, minimum, over a given period of time.
For example, to detect outright stalls where no data has been transferred after 30 seconds: git config annex.stalldetection "1KB/30s"
Or, if you have a remote on a USB drive that is normally capable of several megabytes per second, but has bad sectors where it gets stuck for a long time, you could use: git config remote.usbdrive.annex-stalldetection "1MB/1m"
This is not enabled by default, because it can make git-annex use more resources. To be able to cancel stalls, git-annex has to run transfers in separate processes (one per concurrent job). So it may need to open more connections to a remote than usual, or the communication with those processes may make it a bit slower.
remote.<name>.annex-checkuuid This only affects remotes that have their url pointing to a directory on the same system. git-annex normally checks the uuid of such remotes each time it's run, which lets it transparently deal with different drives being mounted to the location at different times.
Setting annex-checkuuid to false will prevent it from checking the uuid at startup (although the uuid is still verified before making any changes to the remote repository). This may be useful to set to prevent unncessary spin-up or automounting of a drive.
remote.<name>.annex-trustlevel Configures a local trust level for the remote. This overrides the value configured by the trust and untrust commands. The value can be any of "trusted", "semitrusted" or "untrusted".
remote.<name>.annex-availability Can be used to tell git-annex whether a remote is LocallyAvailable or GloballyAvailable. Normally, git-annex determines this automatically.
remote.<name>.annex-speculate-present Set to "true" to make git-annex speculate that this remote may contain the content of any file, even though its normal location tracking does not indicate that it does. This will cause git-annex to try to get all file contents from the remote. Can be useful in setting up a caching remote.
remote.<name>.annex-private When this is set to true, no information about the remote will be recorded in the git-annex branch. This is mostly useful for special remotes, and is set when using git-annex-initremote(1) with the --private option.
remote.<name>.annex-bare Can be used to tell git-annex if a remote is a bare repository or not. Normally, git-annex determines this automatically.
remote.<name>.annex-ssh-options Options to use when using ssh to talk to this remote.
remote.<name>.annex-rsync-options Options to use when using rsync to or from this remote. For example, to force IPv6, and limit the bandwidth to 100Kbyte/s, set it to -6 --bwlimit 100
Note that git-annex-shell has a whitelist of allowed rsync options, and others will not be be passed to the remote rsync. So using some options may break the communication between the local and remote rsyncs.
remote.<name>.annex-rsync-upload-options Options to use when using rsync to upload a file to a remote.
These options are passed after other applicable rsync options, so can be used to override them. For example, to limit upload bandwidth to 10Kbyte/s, set --bwlimit 10.
remote.<name>.annex-rsync-download-options Options to use when using rsync to download a file from a remote.
These options are passed after other applicable rsync options, so can be used to override them.
remote.<name>.annex-rsync-transport The remote shell to use to connect to the rsync remote. Possible values are ssh (the default) and rsh, together with their arguments, for instance ssh -p 2222 -c blowfish; Note that the remote hostname should not appear there, see rsync(1) for details. When the transport used is ssh, connections are automatically cached unless annex.sshcaching is unset.
remote.<name>.annex-bup-split-options Options to pass to bup split when storing content in this remote. For example, to limit the bandwidth to 100Kbyte/s, set it to --bwlimit 100k (There is no corresponding option for bup join.)
remote.<name>.annex-gnupg-options Options to pass to GnuPG when it's encrypting data. For instance, to use the AES cipher with a 256 bits key and disable compression, set it to --cipher-algo AES256 --compress-algo none. (These options take precedence over the default GnuPG configuration, which is otherwise used.)
remote.<name>.annex-gnupg-decrypt-options Options to pass to GnuPG when it's decrypting data. (These options take precedence over the default GnuPG configuration, which is otherwise used.)
annex.ssh-options, annex.rsync-options, annex.rsync-upload-options, annex.rsync-download-options, annex.bup-split-options, annex.gnupg-options, annex.gnupg-decrypt-options
Default options to use if a remote does not have more specific options as described above.
remote.<name>.annex-rsyncurl Used by rsync special remotes, this configures the location of the rsync repository to use. Normally this is automatically set up by git annex initremote, but you can change it if needed.
remote.<name>.annex-buprepo Used by bup special remotes, this configures the location of the bup repository to use. Normally this is automatically set up by git annex initremote, but you can change it if needed.
remote.<name>.annex-borgrepo Used by borg special remotes, this configures the location of the borg repository to use. Normally this is automatically set up by git annex initremote, but you can change it if needed.
remote.<name>.annex-ddarrepo Used by ddar special remotes, this configures the location of the ddar repository to use. Normally this is automatically set up by git annex initremote, but you can change it if needed.
remote.<name>.annex-directory Used by directory special remotes, this configures the location of the directory where annexed files are stored for this remote. Normally this is automatically set up by git annex initremote, but you can change it if needed.
remote.<name>.annex-adb Used to identify remotes on Android devices accessed via adb. Normally this is automatically set up by git annex initremote.
remote.<name>.annex-androiddirectory Used by adb special remotes, this is the directory on the Android device where files are stored for this remote. Normally this is automatically set up by git annex initremote, but you can change it if needed.
remote.<name>.annex-androidserial Used by adb special remotes, this is the serial number of the Android device used by the remote. Normally this is automatically set up by git annex initremote, but you can change it if needed, eg when upgrading to a new Android device.
remote.<name>.annex-s3 Used to identify Amazon S3 special remotes.  Normally this is automatically set up by git annex initremote.
remote.<name>.annex-glacier Used to identify Amazon Glacier special remotes.  Normally this is automatically set up by git annex initremote.
remote.<name>.annex-webdav Used to identify webdav special remotes.  Normally this is automatically set up by git annex initremote.
remote.<name>.annex-tahoe Used to identify tahoe special remotes.  Points to the configuration directory for tahoe.
remote.<name>.annex-gcrypt Used to identify gcrypt special remotes.  Normally this is automatically set up by git annex initremote.
It is set to "true" if this is a gcrypt remote.  If the gcrypt remote is accessible over ssh and has git-annex-shell available to manage it, it's set to "shell".
remote.<name>.annex-git-lfs Used to identify git-lfs special remotes.  Normally this is automatically set up by git annex initremote.
It is set to "true" if this is a git-lfs remote.
remote.<name>.annex-httpalso Used to identify httpalso special remotes.  Normally this is automatically set up by git annex initremote.
remote.<name>.annex-externaltype Used external special remotes to record the type of the remote.
Eg, if this is set to "foo", git-annex will run a "git- annex-remote-foo" program to communicate with the external special remote.
If this is set to "readonly", then git-annex will not run any external special remote program, but will try to access things stored in the remote using http. That only works for some external special remotes, so consult the documentation of the one you are using.
remote.<name>.annex-hooktype Used by hook special remotes to record the type of the remote.
annex.web-options Options to pass to curl when git-annex uses it to download urls (rather than the default built-in url downloader).
For example, to force IPv4 only, set it to "-4".  Or to make curl use your ~/.netrc file, set it to "--netrc".
Setting this option makes git-annex use curl, but only when annex.security.allowed-ip-addresses is configured in a specific way. See its documentation.
annex.youtube-dl-options Options to pass to youtube-dl when using it to find the url to download for a video.
Some options may break git-annex's integration with youtube-dl. For example, the --output option could cause it to store files somewhere git-annex won't find them. Avoid setting here or in the youtube-dl config file any options that cause youtube-dl to download more than one file, or to store the file anywhere other than the current working directory.
annex.aria-torrent-options Options to pass to aria2c when using it to download a torrent.
annex.http-headers HTTP headers to send when downloading from the web. Multiple lines of this option can be set, one per header.
annex.http-headers-command If set, the command is run and each line of its output is used as a HTTP header. This overrides annex.http-headers.
annex.security.allowed-url-schemes List of URL schemes that git-annex is allowed to download content from.  The default is "http https ftp".
Think very carefully before changing this; there are security implications. For example, if it's changed to allow "file" URLs, then anyone who can get a commit into your git-annex repository could git-annex addurl a pointer to a private file located outside that repository, possibly causing it to be copied into your repository and transferred on to other remotes, exposing its content.
Some special remotes support their own domain-specific URL schemes; those are not affected by this configuration setting.
annex.security.allowed-ip-addresses By default, git-annex only makes connections to public IP addresses; it will refuse to use HTTP and other servers on localhost or on a private network.
This setting can override that behavior, allowing access to particular IP addresses that would normally be blocked. For example "127.0.0.1 ::1" allows access to localhost (both IPV4 and IPV6).  To allow access to all IP addresses, use "all"
Think very carefully before changing this; there are security implications. Anyone who can get a commit into your git-annex repository could git annex addurl an url on a private server, possibly causing it to be downloaded into your repository and transferred to other remotes, exposing its content.
Note that, since the interfaces of curl and youtube-dl do not allow these IP address restrictions to be enforced, curl and youtube-dl will never be used unless annex.security.allowed-ip-addresses=all.
To allow accessing local or private IP addresses on only specific ports, use the syntax "[addr]:port". For example, "[127.0.0.1]:80 [127.0.0.1]:443 [::1]:80 [::1]:443" allows localhost on the http ports only.
annex.security.allowed-http-addresses Old name for annex.security.allowed-ip-addresses.  If set, this is treated the same as having annex.security.allowed-ip-addresses set.
annex.security.allow-unverified-downloads For security reasons, git-annex refuses to download content from most special remotes when it cannot check a hash to verify that the correct content was downloaded. This particularly impacts downloading the content of URL or WORM keys, which lack hashes.
The best way to avoid problems due to this is to migrate files away from such keys, before their content reaches a special remote.  See git-annex-migrate(1).
When the content is only available from a special remote, you can use this configuration to force git-annex to download it.  But you do so at your own risk, and it's very important you read and understand the information below first!
Downloading unverified content from encrypted special remotes is prevented, because the special remote could send some other encrypted content than what you expect, causing git-annex to decrypt data that you never checked into git-annex, and risking exposing the decrypted data to any non-encrypted remotes you send content to.
Downloading unverified content from (non-encrypted) external special remotes is prevented, because they could follow http redirects to web servers on localhost or on a private network, or in some cases to a file:/// url.
If you decide to bypass this security check, the best thing to do is to only set it temporarily while running the command that gets the file.  The value to set the config to is "ACKTHPPT".  For example:
git -c annex.security.allow-unverified-downloads=ACKTHPPT annex get myfile
It would be a good idea to check that it downloaded the file you expected, too.
remote.<name>.annex-security-allow-unverified-downloads Per-remote configuration of annex.security.allow-unverified-downloads.
annex.delayadd
Makes the watch and assistant commands delay for the specified number of seconds before adding a newly created file to the annex. Normally this is not needed, because they already wait for all writers of the file to close it.
Note that this only delays adding files created while the daemon is running. Changes made when it is not running will be added immediately the next time it is started up.
annex.expireunused Controls what the assistant does about unused file contents that are stored in the repository.
The default is false, which causes all old and unused file contents to be retained, unless the assistant is able to move them to some other repository (such as a backup repository).
Can be set to a time specification, like "7d" or "1m", and then file contents that have been known to be unused for a week or a month will be deleted.
annex.fscknudge When set to false, prevents the webapp from reminding you when using repositories that lack consistency checks.
annex.autoupgrade When set to ask (the default), the webapp will check for new versions and prompt if they should be upgraded to. When set to true, automatically upgrades without prompting (on some supported platforms). When set to false, disables any upgrade checking.
Note that upgrade checking is only done when git-annex is installed from one of the prebuilt images from its website. This does not bypass e.g., a Linux distribution's own upgrade handling code.
This setting also controls whether to restart the git-annex assistant when the git-annex binary is detected to have changed. That is useful no matter how you installed git-annex.
annex.autocommit Set to false to prevent the git-annex assistant and git-annex sync from automatically committing changes to files in the repository.
annex.startupscan Set to false to prevent the git-annex assistant from scanning the repository for new and changed files on startup. This will prevent it from noticing changes that were made while it was not running, but can be a useful performance tweak for a large repository.
annex.listen Configures which address the webapp listens on. The default is localhost.  Can be either an IP address, or a hostname that resolves to the desired address.
CONFIGURATION VIA .gitattributes The key-value backend used when adding a new file to the annex can be configured on a per-file-type basis via .gitattributes files. In the file, the annex.backend attribute can be set to the name of the backend to use. For example, this here's how to use the WORM backend by default, but the SHA256E backend for ogg files:
* annex.backend=WORM *.ogg annex.backend=SHA256E
There is a annex.largefiles attribute, which is used to configure which files are large enough to be added to the annex. Since attributes cannot contain spaces, it is difficult to use for more complex annex.largefiles settings. Setting annex.largefiles in git-annex-config(1) is an easier way to configure it across all clones of the repository.  See git- annex-matching-expression(1) for details on the syntax.
The numcopies and mincopies settings can also be configured on a per-file-type basis via the annex.numcopies and annex.mincopies attributes in .gitattributes files. This overrides other settings.  For example, this makes two copies be needed for wav files and 3 copies for flac files:
*.wav annex.numcopies=2 *.flac annex.numcopies=3
Note that setting numcopies or mincopies to 0 is very unsafe.
These settings are honored by git-annex whenever it's operating on a matching file. However, when using --all, --unused, or --key to specify keys to operate on, git-annex is operating on keys and not files, so will not honor the settings from .gitattributes. For this reason, the git annex numcopies and git annex mincopies commands are useful to configure a global default.
Also note that when using views, only the toplevel .gitattributes file is preserved in the view, so other settings in other files won't have any effect.
git-annex, when called as a git subcommand, may return exit codes 0 or 1 for success or failures, or, more rarely, 127 or 128 for certain very specific failures.  git-annex itself should return 0 on success and 1 on failure, unless the --time-limit=time option is hit, in which case it returns with exit code 101.
These environment variables are used by git-annex when set:
GIT_WORK_TREE, GIT_DIR Handled the same as they are by git, see git(1)
GIT_SSH, GIT_SSH_COMMAND Handled similarly to the same as described in git(1).  The one difference is that git-annex will sometimes pass an additional "-n" parameter to these, as the first parameter, to prevent ssh from reading from stdin. Since that can break existing uses of these environment variables that don't expect the extra parameter, you will need to set GIT_ANNEX_USE_GIT_SSH=1 to make git-annex support these.
Note that setting either of these environment variables prevents git-annex from automatically enabling ssh connection caching (see annex.sshcaching), so it will slow down some operations with remotes over ssh. It's up to you to enable ssh connection caching if you need it; see ssh's documentation.
Also, annex.ssh-options and remote.<name>.annex-ssh-options won't have any effect when these envionment variables are set.
Usually it's better to configure any desired options through your ~/.ssh/config file, or by setting annex.ssh-options.
GIT_ANNEX_VECTOR_CLOCK Normally git-annex timestamps lines in the log files committed to the git-annex branch. Setting this environment variable to a number will make git-annex use that rather than the current number of seconds since the UNIX epoch. Note that decimal seconds are supported.
This is only provided for advanced users who either have a better way to tell which commit is current than the local clock, or who need to avoid embedding timestamps for policy reasons. Misuse of this environment variable can confuse git-annex's book-keeping, sometimes in ways that git annex fsck is unable to repair.
Some special remotes use additional environment variables for authentication etc. For example, AWS_ACCESS_KEY_ID and GIT_ANNEX_P2P_AUTHTOKEN. See special remote documentation.
These files are used by git-annex:
.git/annex/objects/ in your git repository contains the annexed file contents that are currently available. Annexed files in your git repository symlink to that content.
.git/annex/ in your git repository contains other run-time information used by git-annex.
~/.config/git-annex/autostart is a list of git repositories to start the git-annex assistant in.
.git/hooks/pre-commit-annex in your git repository will be run whenever a commit is made to the HEAD branch, either by git commit, git-annex sync, or the git-annex assistant.
.git/hooks/post-update-annex in your git repository will be run whenever the git-annex branch is updated. You can make this hook run git update-server-info when publishing a git-annex repository by http.
More git-annex documentation is available on its web site, <https://git- annex.branchable.com/>
If git-annex is installed from a package, a copy of its documentation should be included, in, for example, /usr/share/doc/git-annex/.
Joey Hess <id@joeyh.name>
<https://git-annex.branchable.com/>
KEEPASS2(1)                  General Commands Manual                 KEEPASS2(1)
keepass2 - password manager
keepass2
KeePass2 is a free/open-source password manager or safe which helps you to manage your passwords in a secure way. You can put all your passwords in one database, which is locked with one master key or a key file. So you only have to remember one single master password to unlock the whole database. The databases are encrypted using AES-256.
--auto-type invokes global auto-type
--lock-all lock databases of all KeePass instances
--unlock-all unlock databases of all KeePass instances
--exit-all exit all KeePass instances
This manual page was written by Julian Taylor <jtaylor.debian@googlemail.com>, for the Debian project (but may be used by others).
GIT-BRANCH(1)                      Git Manual                      GIT-BRANCH(1)
git-branch - List, create, or delete branches
git branch [--color[=<when>] | --no-color] [--show-current] [-v [--abbrev=<n> | --no-abbrev]] [--column[=<options>] | --no-column] [--sort=<key>] [--merged [<commit>]] [--no-merged [<commit>]] [--contains [<commit>]] [--no-contains [<commit>]] [--points-at <object>] [--format=<format>] [(-r | --remotes) | (-a | --all)] [--list] [<pattern>...] git branch [--track | --no-track] [-f] <branchname> [<start-point>] git branch (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>] git branch --unset-upstream [<branchname>] git branch (-m | -M) [<oldbranch>] <newbranch> git branch (-c | -C) [<oldbranch>] <newbranch> git branch (-d | -D) [-r] <branchname>... git branch --edit-description [<branchname>]
If --list is given, or if there are no non-option arguments, existing branches are listed; the current branch will be highlighted in green and marked with an asterisk. Any branches checked out in linked worktrees will be highlighted in cyan and marked with a plus sign. Option -r causes the remote-tracking branches to be listed, and option -a shows both local and remote branches.
If a <pattern> is given, it is used as a shell wildcard to restrict the output to matching branches. If multiple patterns are given, a branch is shown if it matches any of the patterns.
Note that when providing a <pattern>, you must use --list; otherwise the command may be interpreted as branch creation.
With --contains, shows only the branches that contain the named commit (in other words, the branches whose tip commits are descendants of the named commit), --no-contains inverts it. With --merged, only branches merged into the named commit (i.e. the branches whose tip commits are reachable from the named commit) will be listed. With --no-merged only branches not merged into the named commit will be listed. If the <commit> argument is missing it defaults to HEAD (i.e. the tip of the current branch).
The command’s second form creates a new branch head named <branchname> which points to the current HEAD, or <start-point> if given. As a special case, for <start-point>, you may use "A...B" as a shortcut for the merge base of A and B if there is exactly one merge base. You can leave out at most one of A and B, in which case it defaults to HEAD.
Note that this will create the new branch, but it will not switch the working tree to it; use "git switch <newbranch>" to switch to the new branch.
When a local branch is started off a remote-tracking branch, Git sets up the branch (specifically the branch.<name>.remote and branch.<name>.merge configuration entries) so that git pull will appropriately merge from the remote-tracking branch. This behavior may be changed via the global branch.autoSetupMerge configuration flag. That setting can be overridden by using the --track and --no-track options, and changed later using git branch --set-upstream-to.
With a -m or -M option, <oldbranch> will be renamed to <newbranch>. If <oldbranch> had a corresponding reflog, it is renamed to match <newbranch>, and a reflog entry is created to remember the branch renaming. If <newbranch> exists, -M must be used to force the rename to happen.
The -c and -C options have the exact same semantics as -m and -M, except instead of the branch being renamed, it will be copied to a new name, along with its config and reflog.
With a -d or -D option, <branchname> will be deleted. You may specify more than one branch for deletion. If the branch currently has a reflog then the reflog will also be deleted.
Use -r together with -d to delete remote-tracking branches. Note, that it only makes sense to delete remote-tracking branches if they no longer exist in the remote repository or if git fetch was configured not to fetch them again. See also the prune subcommand of git-remote(1) for a way to clean up all obsolete remote-tracking branches.
-d, --delete Delete a branch. The branch must be fully merged in its upstream branch, or in HEAD if no upstream was set with --track or --set-upstream-to.
-D Shortcut for --delete --force.
--create-reflog Create the branch’s reflog. This activates recording of all changes made to the branch ref, enabling use of date based sha1 expressions such as "<branchname>@{yesterday}". Note that in non-bare repositories, reflogs are usually enabled by default by the core.logAllRefUpdates config option. The negated form --no-create-reflog only overrides an earlier --create-reflog, but currently does not negate the setting of core.logAllRefUpdates.
-f, --force Reset <branchname> to <startpoint>, even if <branchname> exists already. Without -f, git branch refuses to change an existing branch. In combination with -d (or --delete), allow deleting the branch irrespective of its merged status, or whether it even points to a valid commit. In combination with -m (or --move), allow renaming the branch even if the new branch name already exists, the same applies for -c (or --copy).
-m, --move Move/rename a branch, together with its config and reflog.
-M Shortcut for --move --force.
-c, --copy Copy a branch, together with its config and reflog.
-C Shortcut for --copy --force.
--color[=<when>] Color branches to highlight current, local, and remote-tracking branches. The value must be always (the default), never, or auto.
--no-color Turn off branch colors, even when the configuration file gives the default to color output. Same as --color=never.
-i, --ignore-case Sorting and filtering branches are case insensitive.
--column[=<options>], --no-column Display branch listing in columns. See configuration variable column.branch for option syntax.  --column and --no-column without options are equivalent to always and never respectively.
This option is only applicable in non-verbose mode.
-r, --remotes List or delete (if used with -d) the remote-tracking branches. Combine with --list to match the optional pattern(s).
-a, --all List both remote-tracking branches and local branches. Combine with --list to match optional pattern(s).
-l, --list List branches. With optional <pattern>..., e.g.  git branch --list 'maint-*', list only the branches that match the pattern(s).
--show-current Print the name of the current branch. In detached HEAD state, nothing is printed.
-v, -vv, --verbose When in list mode, show sha1 and commit subject line for each head, along with relationship to upstream branch (if any). If given twice, print the path of the linked worktree (if any) and the name of the upstream branch, as well (see also git remote show <remote>). Note that the current worktree’s HEAD will not have its path printed (it will always be your current directory).
-q, --quiet Be more quiet when creating or deleting a branch, suppressing non-error messages.
--abbrev=<n> In the verbose listing that show the commit object name, show the shortest prefix that is at least <n> hexdigits long that uniquely refers the object. The default value is 7 and can be overridden by the core.abbrev config option.
--no-abbrev Display the full sha1s in the output listing rather than abbreviating them.
-t, --track When creating a new branch, set up branch.<name>.remote and branch.<name>.merge configuration entries to mark the start-point branch as "upstream" from the new branch. This configuration will tell git to show the relationship between the two branches in git status and git branch -v. Furthermore, it directs git pull without arguments to pull from the upstream when the new branch is checked out.
This behavior is the default when the start point is a remote-tracking branch. Set the branch.autoSetupMerge configuration variable to false if you want git switch, git checkout and git branch to always behave as if --no-track were given. Set it to always if you want this behavior when the start-point is either a local or remote-tracking branch.
--no-track Do not set up "upstream" configuration, even if the branch.autoSetupMerge configuration variable is true.
--set-upstream As this option had confusing syntax, it is no longer supported. Please use --track or --set-upstream-to instead.
-u <upstream>, --set-upstream-to=<upstream> Set up <branchname>'s tracking information so <upstream> is considered <branchname>'s upstream branch. If no <branchname> is specified, then it defaults to the current branch.
--unset-upstream Remove the upstream information for <branchname>. If no branch is specified it defaults to the current branch.
--edit-description Open an editor and edit the text to explain what the branch is for, to be used by various other commands (e.g.  format-patch, request-pull, and merge (if enabled)). Multi-line explanations may be used.
--contains [<commit>] Only list branches which contain the specified commit (HEAD if not specified). Implies --list.
--no-contains [<commit>] Only list branches which don’t contain the specified commit (HEAD if not specified). Implies --list.
--merged [<commit>] Only list branches whose tips are reachable from the specified commit (HEAD if not specified). Implies --list.
--no-merged [<commit>] Only list branches whose tips are not reachable from the specified commit (HEAD if not specified). Implies --list.
<branchname> The name of the branch to create or delete. The new branch name must pass all checks defined by git-check-ref-format(1). Some of these checks may restrict the characters allowed in a branch name.
<start-point> The new branch head will point to this commit. It may be given as a branch name, a commit-id, or a tag. If this option is omitted, the current HEAD will be used instead.
<oldbranch> The name of an existing branch to rename.
<newbranch> The new name for an existing branch. The same restrictions as for <branchname> apply.
--sort=<key> Sort based on the key given. Prefix - to sort in descending order of the value. You may use the --sort=<key> option multiple times, in which case the last key becomes the primary key. The keys supported are the same as those in git for-each-ref. Sort order defaults to the value configured for the branch.sort variable if exists, or to sorting based on the full refname (including refs/...  prefix). This lists detached HEAD (if present) first, then local branches and finally remote-tracking branches. See git-config(1).
--points-at <object> Only list branches of the given object.
--format <format> A string that interpolates %(fieldname) from a branch ref being shown and the object it points at. The format is the same as that of git- for-each-ref(1).
pager.branch is only respected when listing branches, i.e., when --list is used or implied. The default is to use a pager. See git-config(1).
Start development from a known tag
$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 $ cd my2.6 $ git branch my2.6.14 v2.6.14   (1) $ git switch my2.6.14
1. This step and the next one could be combined into a single step with "checkout -b my2.6.14 v2.6.14".
Delete an unneeded branch
$ git clone git://git.kernel.org/.../git.git my.git $ cd my.git $ git branch -d -r origin/todo origin/html origin/man   (1) $ git branch -D test                                    (2)
1. Delete the remote-tracking branches "todo", "html" and "man". The next fetch or pull will create them again unless you configure them not to. See git-fetch(1). 2. Delete the "test" branch even if the "master" branch (or whichever branch is currently checked out) does not have all commits from the test branch.
Listing branches from a specific remote
$ git branch -r -l '<remote>/<pattern>'                 (1) $ git for-each-ref 'refs/remotes/<remote>/<pattern>'    (2)
1. Using -a would conflate <remote> with any local branches you happen to have been prefixed with the same <remote> pattern. 2. for-each-ref can take a wide range of options. See git-for-each- ref(1)
Patterns will normally need quoting.
If you are creating a branch that you want to switch to immediately, it is easier to use the "git switch" command with its -c option to do the same thing with a single command.
The options --contains, --no-contains, --merged and --no-merged serve four related but different purposes:
•   --contains <commit> is used to find all branches which will need special attention if <commit> were to be rebased or amended, since those branches contain the specified <commit>.
•   --no-contains <commit> is the inverse of that, i.e. branches that don’t contain the specified <commit>.
•   --merged is used to find all branches which can be safely deleted, since those branches are fully contained by HEAD.
•   --no-merged is used to find branches which are candidates for merging into HEAD, since those branches are not fully contained by HEAD.
When combining multiple --contains and --no-contains filters, only references that contain at least one of the --contains commits and contain none of the --no-contains commits are shown.
When combining multiple --merged and --no-merged filters, only references that are reachable from at least one of the --merged commits and from none of the --no-merged commits are shown.
1. “Understanding history: What is a branch?” file:///usr/share/doc/git-doc/user-manual.html#what-is-a-branch
git-check-ref-format(1), git-fetch(1), git-remote(1), “Understanding history: What is a branch?”[1] in the Git User’s Manual.
LOREM(1)               User Contributed Perl Documentation              LOREM(1)
lorem - Generate random Latin looking text using Text::Lorem
Generate 3 paragraphs of Latin looking text:
$ lorem -p 3
Generate 5 Latin looking words:
$ lorem -w 5
Generate a Latin looking sentence:
$ lorem -s 1
lorem is a simple command-line wrapper around the "Text::Lorem" module. It provides the same three basic methods:  Generate "words", generate "sentences", and generate "paragraphs".
VIRT-MANAGER(1)              Virtualization Support              VIRT-MANAGER(1)
virt-manager - Graphical tool for managing libvirt VMs
virt-manager [OPTIONS]
virt-manager is a desktop tool for managing virtual machines. It provides the ability to control the lifecycle of existing machines (bootup/shutdown,pause/resume,suspend/restore), provision new virtual machines and various types of store, manage virtual networks, access the graphical console of virtual machines, and view performance statistics, all done locally or remotely.
Standard GTK options like --g-fatal-warnings are accepted.
The following options are accepted when running virt-manager
-h, --help Display command line help summary
--version Show virt-manager's version number and exit
-c, --connect Specify the hypervisor connection URI
--debug List debugging output to the console (normally this is only logged in ~/.cache/virt-manager/virt-manager.log). This function implies --no-fork.
--no-fork Don't fork virt-manager off into the background: run it blocking the current terminal. Useful for seeing possible errors dumped to stdout/stderr.
For these options, only the requested window will be shown, the manaer window will not be run in this case. Connection autostart will also be disabled. All these options require specifying a manual --connect URI.
--show-domain-creator Display the wizard for creating new virtual machines
--show-domain-editor NAME|ID|UUID Display the dialog for editing properties of the virtual machine with unique ID matching either the domain name, ID, or UUID
--show-domain-performance NAME|ID|UUID Display the dialog for monitoring performance of the virtual machine with unique ID matching either the domain name, ID, or UUID
--show-domain-console NAME|ID|UUID Display the virtual console of the virtual machine with unique ID matching either the domain name, ID, or UUID
--show-host-summary Display the host/connection details window.
Please see https://virt-manager.org/bugs/
Copyright (C) Red Hat, Inc, and various contributors.  This is free software. You may redistribute copies of it under the terms of the GNU General Public License https://www.gnu.org/licenses/gpl.html. There is NO WARRANTY, to the extent permitted by law.
virsh(1), virt-viewer(1), the project website https://virt-manager.org
compose(3rheolef)                    rheolef                   compose(3rheolef)
compose - n-ary function application in expressions (rheolef-7.1)
template <class Function, class... Expressions> Expression compose (const Function& f, const Expressions&... exprs);
Compose a n-ary function f with n fields in interpolate(3) and integrate(3) nonlinear expressions.
The compose operator is used for applying a user-provided function to a field:
Float f (Float u) { return 1/u + sqrt(u); } ... field vh = interpolate (Xh, compose(f, uh));
When two arguments are involved:
Float g (Float u, Float v) { return v/u + sqrt(u*v); } ... field wh = interpolate (Xh, compose(g, uh, vh));
The compose operator supports general n-ary functions and class- functions.
The compose function supports also the method of characteristic(2) used e.g. for convection-diffusion problems:
characteristic X (-delta_t*uh); test v (Xh); field lh = integrate (compose(uh,X)*v);
This documentation has been generated from file main/lib/compose.h
Pierre  Saramito  <Pierre.Saramito@imag.fr>
Copyright   (C)  2000-2018  Pierre  Saramito  <Pierre.Saramito@imag.fr> GPLv3+: GNU GPL version 3 or later  <http://gnu.org/licenses/gpl.html>. This  is  free  software:  you  are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
Mono(Mono 1.1.x)                                                Mono(Mono 1.1.x)
monodis - CIL image content dumper and disassembler.
monodis [-h] [--help] [--output=FILENAME] [--mscorlib] [--assembly] [--assemblyref] [--classlayout] [--constant] [--customattr] [--declsec] [--event] [--exported] [--fields] [--file] [--forward-decls] [--genericpar] [--implmap] [--interface] [--manifest] [--marshal] [--memberref] [--method] [--methodimpl] [--methodsem] [--methodspec] [--module] [--moduleref] [--mresources] [--presources] [--nested] [--param] [--parconst] [--property] [--propertymap] [--standalonesig] [--typedef] [--typeref] [--typespec] [--blob] [--strings] [--userstrings] [FILES...]
The monodis program is used to dump the contents an ECMA/ISO CIL image (contained in .EXE files that contain extended PE/COFF CIL code).
To roundtrip assemblies using ilasm, it is best to use the --output argument, as that will make monodis save the embedded resources in files that can later be properly embedded back by ilasm.
Additionally, the tool can be used to dump the contents of the various ECMA CIL metadata tables.
The following Generic options are supported:
--help , -h Displays usage instructions.
--output=FILENAME Write output into FILENAME and dump any embedded managed resources.
--mscorlib For non-corlib assemblies, use "mscorlib" as the assembly name. This is useful for round-tripping the IL with ilasm.
--show-method-tokens Display tokens for disassembled methods.
--show-tokens Display tokens for strings, types, methods, fields, etc.
The following options are used to display metadata tables instead of disassembling the CIL image.
--assembly Dumps the contents of the Assembly table.
--assemblyref Dumps the contents of the AssemblyRef table.
--classlayout Dumps the contents of the ClassLayout table.
--constant Dumps the contents of the Constant table.
--customattr Dumps the contents of the CustomAttribute table.
--declsec Dumps the contents of the DeclSec table.
--event Dumps the contents of the Event table.
--exported Dumps the contents of the ExportedType table.
--fields Dumps the contents of the Field table.
--file Dumps the contents of the File table.
--forward-decls Dumps forward declarations for classes.
--genericpar Dumps the contents of the GenericParam table.
--implmap Dumps the contents of the ImplMap table.
--interface Dumps the contents of the InterfaceImpl table.
--manifest Dumps the contents of the ManifestResource table.
--marshal Dumps the contents of the FieldMarshal table.
--memberref Dumps the contents of the MemberRef table.
--method Dumps the contents of the MethodDef table.
--methodimpl Dumps the contents of the MethodImpl table.
--methodspec Dumps the contents of the MethodSpec table.
--methodsem Dumps the contents of the MethodSemantics table.
--module Dumps the contents of the Module table.
--moduleref Dumps the contents of the ModuleRef table.
--mresources Saves all the managed resources embedded in the assembly into the current directory.   To get a list of the embedded resources use the --manifest option.
--presources Prints offsets and names of manifest resources embedded in the assembly.
--nested Dumps the contents of the NestedClass table.
--param Dumps the contents of the Param table.
--parconst Dumps the contents of the GenericParameterConstraint table.
--property Dumps the contents of the Property table.
--propertymap Dumps the contents of the PropertyMap table.
--standalonesig Dumps the contents of the StandAloneSig table.
--typedef Dumps the contents of the TypeDef table.
--typespec Dumps the contents of the TypeSpec table.
--typeref Dumps the contents of the TypeRef table.
--blob Dumps the entire contents of the blob stream as hex.
--strings Dumps the contents of the Strings heap.
--userstrings Dumps the contents of the User-Strings heap
If no flags are specified the program dumps the content of the image in a format that can be used to rountrip the code.
MONO_PATH Provides a search path to mono and mint where to look for library files.  Directories are separated by the platform path separator (colons on unix). Example: /home/username/lib:/usr/local/mono/lib
monodis was written by Miguel de Icaza, Paolo Molaro and Dietmar Maurer.
pedump(1)
GRUB-MKCONFIG(8)         System Administration Utilities        GRUB-MKCONFIG(8)
grub-mkconfig - generate a GRUB configuration file
grub-mkconfig [OPTION]
Generate a grub config file
-o, --output=FILE output generated config to FILE [default=stdout]
-h, --help print this message and exit
-V, --version print the version information and exit
Report bugs to <bug-grub@gnu.org>.
grub-install(8)
The full documentation for grub-mkconfig is maintained as a Texinfo manual.  If the info and grub-mkconfig programs are properly installed at your site, the command
info grub-mkconfig
LOGNAME(1)                        User Commands                       LOGNAME(1)
logname - print user´s login name
logname [OPTION]
Print the user's login name.
Written by FIXME: unknown.
Copyright © 2021 Free Software Foundation, Inc.  License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it.  There is NO WARRANTY, to the extent permitted by law.
getlogin(3)
Full documentation <https://www.gnu.org/software/coreutils/logname> or available locally via: info '(coreutils) logname invocation'
GIT-BUGREPORT(1)                   Git Manual                   GIT-BUGREPORT(1)