neulab/tldr huggingface dataset:
-draftmode Sets \pdfdraftmode so pdfTeX doesn't write a PDF and doesn't read any included images, thus speeding up execution.
-enc   Enable the encTeX extensions.  This option is only effective in combination with -ini.  For documentation of the encTeX extensions see http://www.olsak.net/enctex.html.
-etex  Enable the e-TeX extensions.  This option is only effective in combination with -ini.  See etex(1).
-file-line-error Print error messages in the form file:line:error which is similar to the way many compilers format them.
-no-file-line-error Disable printing error messages in the file:line:error style.
-file-line-error-style This is the old name of the -file-line-error option.
-fmt format Use format as the name of the format to be used, instead of the name by which pdfTeX was called or a %& line.
-halt-on-error Exit with an error code when an error is encountered during processing.
-help  Print help message and exit.
-ini   Start in INI mode, which is used to dump formats.  The INI mode can be used for typesetting, but no format is preloaded, and basic initializations like setting catcodes may be required.
-interaction mode Sets the interaction mode.  The mode can be either batchmode, nonstopmode, scrollmode, and errorstopmode.  The meaning of these modes is the same as that of the corresponding \commands.
-ipc   Send DVI or PDF output to a socket as well as the usual output file.  Whether this option is available is the choice of the installer.
-ipc-start As -ipc, and starts the server at the other end as well.  Whether this option is available is the choice of the installer.
-jobname name Use name for the job name, instead of deriving it from the name of the input file.
-kpathsea-debug bitmask Sets path searching debugging flags according to the bitmask.  See the Kpathsea manual for details.
-mktex fmt Enable mktexfmt, where fmt must be either tex or tfm.
-mltex Enable MLTeX extensions.  Only effective in combination with -ini.
-no-mktex fmt Disable mktexfmt, where fmt must be either tex or tfm.
-output-comment string In DVI mode, use string for the DVI file comment instead of the date. This option is ignored in PDF mode.
-output-directory directory Write output files in directory instead of the current directory. Look up input files in directory first, the along the normal search path.
-output-format format Set the output format mode, where format must be either pdf or dvi.  This also influences the set of graphics formats understood by pdfTeX.
-parse-first-line If the first line of the main input file begins with %& parse it to look for a dump name or a -translate-file option.
-no-parse-first-line Disable parsing of the first line of the main input file.
-progname name Pretend to be program name.  This affects both the format used and the search paths.
-recorder Enable the filename recorder.  This leaves a trace of the files opened for input and output in a file with extension .fls.
-shell-escape Enable the \write18{command} construct.  The command can be any shell command.  This construct is normally disallowed for security reasons.
-no-shell-escape Disable the \write18{command} construct, even if it is enabled in the texmf.cnf file.
-shell-restricted Enable restricted \write18{}, as explained in the ``Shell escapes'' section of the Web2c Texinfo manual.
-src-specials In DVI mode, insert source specials into the DVI file. This option is ignored in PDF mode.
-src-specials where In DVI mode, insert source specials in certain places of the DVI file. The where argument is a comma-separated value list: cr, display, hbox, math, par, parent, or vbox.  This option is ignored in PDF mode.
-synctex NUMBER generate SyncTeX data for previewers according to bits of NUMBER. See the synctex manual page for details.
-translate-file tcxname Use the tcxname translation table to set the mapping of input characters and re-mapping of output characters.
-default-translate-file tcxname Like -translate-file except that a %& line can overrule this setting.
-8bit  make all characters printable by default.
See the Kpathsea library documentation (e.g., the `Path specifications' node) for precise details of how the environment variables are used.  The kpsewhich utility can be used to query the values of the variables.
One caveat: In most pdfTeX formats, you cannot use ~ in a filename you give directly to pdfTeX, because ~ is an active character in TeX, and hence is expanded, not taken as part of the filename. Other programs, such as Metafont, do not have this problem.
TEXMFOUTPUT Normally, pdfTeX puts its output files in the current directory. If any output file cannot be opened there, it tries to open it in the directory specified in the environment variable TEXMFOUTPUT. There is no default value for that variable.  For example, if you say pdftex paper and the current directory is not writable and TEXMFOUTPUT has the value /tmp, pdfTeX attempts to create /tmp/paper.log (and /tmp/paper.pdf, if any output is produced.) TEXMFOUTPUT is also checked for input files, as TeX often generates files that need to be subsequently read; for input, no suffixes (such as ``.tex'') are added by default, the input name is simply checked as given.
TEXINPUTS Search path for \input and \openin files.  This normally starts with ``.'', so that user files are found before system files.  An empty path component will be replaced with the paths defined in the texmf.cnf file.  For example, set TEXINPUTS to ".:/home/user/tex:" to prepend the current directory and ``/home/user/tex'' to the standard search path.
TEXFORMATS Search path for format files.
TEXEDIT Command template for switching to editor.  The default, usually vi, is set when pdfTeX is compiled.
TFMFONTS Search path for font metric (.tfm) files.
SOURCE_DATE_EPOCH If set, its value, taken to be in epoch-seconds, will be used for the timestamps in the PDF output, such as the CreationDate and ModDate keys.  This is useful for making reproducible builds.
FORCE_SOURCE_DATE If set to the value "1", the time-related TeX primitives (\year, \month, \day, \time) are also initialized from the value of SOURCE_DATE_EPOCH.  This is not recommended if there is any viable alternative. pdfTeX also has several primitives to support reproducible builds, which are preferable to setting these environment variables; see the main manual.
Many, many more environment variables may be consulted related to path searching.  See the Kpathsea manual.
The location of the files mentioned below varies from system to system. Use the kpsewhich utility to find their locations.
pdftex.map Font name mapping definitions.
*.tfm  Metric files for pdfTeX's fonts.
*.fmt  Predigested pdfTeX format (.fmt) files.
This version of pdfTeX fails to trap arithmetic overflow when dimensions are added or subtracted.  Cases where this occurs are rare, but when it does the generated DVI or PDF file will be invalid.
pdfTeX is available for a large variety of machine architectures and operating systems.  pdfTeX is part of all major TeX distributions. The pdfTeX home page: http://www.pdftex.org. pdfTeX on CTAN: https://ctan.org/pkg/pdftex. pdfTeX mailing list for all discussion: https://lists.tug.org/pdftex.
This manual page is not meant to be exhaustive.  The complete documentation for this version of pdfTeX can be found in the pdfTeX user manual and the Texinfo manuals Kpathsea library, Web2C: A TeX implementation.  These manuals, and more, can be accessed from the pdfTeX or CTAN web pages given above.
Some related programs: epstopdf(1), etex(1), latex(1), luatex(1), mptopdf(1), tex(1), mf(1).
The primary authors of pdfTeX are Han The Thanh, Petr Sojka, Jiri Zlatuska, and Peter Breitenlohner (eTeX).
TeX was designed by Donald E. Knuth, who implemented it using his Web system for Pascal programs.  It was ported to Unix at Stanford by Howard Trickey, and at Cornell by Pavel Curtis.  The version now offered with the Unix TeX distribution is that generated by the Web to C system (web2c), originally written by Tomas Rokicki and Tim Morgan.  The encTeX extensions were written by Petr Olsak.
GIT-DAEMON(1)                      Git Manual                      GIT-DAEMON(1)
git-daemon - A really simple server for Git repositories
git daemon [--verbose] [--syslog] [--export-all] [--timeout=<n>] [--init-timeout=<n>] [--max-connections=<n>] [--strict-paths] [--base-path=<path>] [--base-path-relaxed] [--user-path | --user-path=<path>] [--interpolated-path=<pathtemplate>] [--reuseaddr] [--detach] [--pid-file=<file>] [--enable=<service>] [--disable=<service>] [--allow-override=<service>] [--forbid-override=<service>] [--access-hook=<path>] [--[no-]informative-errors] [--inetd | [--listen=<host_or_ipaddr>] [--port=<n>] [--user=<user> [--group=<group>]]] [--log-destination=(stderr|syslog|none)] [<directory>...]
A really simple TCP Git daemon that normally listens on port "DEFAULT_GIT_PORT" aka 9418. It waits for a connection asking for a service, and will serve that service if it is enabled.
It verifies that the directory has the magic file "git-daemon-export-ok", and it will refuse to export any Git directory that hasn’t explicitly been marked for export this way (unless the --export-all parameter is specified). If you pass some directory paths as git daemon arguments, you can further restrict the offers to a whitelist comprising of those.
By default, only upload-pack service is enabled, which serves git fetch-pack and git ls-remote clients, which are invoked from git fetch, git pull, and git clone.
This is ideally suited for read-only updates, i.e., pulling from Git repositories.
An upload-archive also exists to serve git archive.
--strict-paths Match paths exactly (i.e. don’t allow "/foo/repo" when the real path is "/foo/repo.git" or "/foo/repo/.git") and don’t do user-relative paths.  git daemon will refuse to start when this option is enabled and no whitelist is specified.
--base-path=<path> Remap all the path requests as relative to the given path. This is sort of "Git root" - if you run git daemon with --base-path=/srv/git on example.com, then if you later try to pull git://example.com/hello.git, git daemon will interpret the path as /srv/git/hello.git.
--base-path-relaxed If --base-path is enabled and repo lookup fails, with this option git daemon will attempt to lookup without prefixing the base path. This is useful for switching to --base-path usage, while still allowing the old paths.
--interpolated-path=<pathtemplate> To support virtual hosting, an interpolated path template can be used to dynamically construct alternate paths. The template supports %H for the target hostname as supplied by the client but converted to all lowercase, %CH for the canonical hostname, %IP for the server’s IP address, %P for the port number, and %D for the absolute path of the named repository. After interpolation, the path is validated against the directory whitelist.
--export-all Allow pulling from all directories that look like Git repositories (have the objects and refs subdirectories), even if they do not have the git-daemon-export-ok file.
--inetd Have the server run as an inetd service. Implies --syslog (may be overridden with --log-destination=). Incompatible with --detach, --port, --listen, --user and --group options.
--listen=<host_or_ipaddr> Listen on a specific IP address or hostname. IP addresses can be either an IPv4 address or an IPv6 address if supported. If IPv6 is not supported, then --listen=hostname is also not supported and --listen must be given an IPv4 address. Can be given more than once. Incompatible with --inetd option.
--port=<n> Listen on an alternative port. Incompatible with --inetd option.
--init-timeout=<n> Timeout (in seconds) between the moment the connection is established and the client request is received (typically a rather low value, since that should be basically immediate).
--timeout=<n> Timeout (in seconds) for specific client sub-requests. This includes the time it takes for the server to process the sub-request and the time spent waiting for the next client’s request.
--max-connections=<n> Maximum number of concurrent clients, defaults to 32. Set it to zero for no limit.
--syslog Short for --log-destination=syslog.
--log-destination=<destination> Send log messages to the specified destination. Note that this option does not imply --verbose, thus by default only error conditions will be logged. The <destination> must be one of:
stderr Write to standard error. Note that if --detach is specified, the process disconnects from the real standard error, making this destination effectively equivalent to none.
syslog Write to syslog, using the git-daemon identifier.
none Disable all logging.
The default destination is syslog if --inetd or --detach is specified, otherwise stderr.
--user-path, --user-path=<path> Allow ~user notation to be used in requests. When specified with no parameter, requests to git://host/~alice/foo is taken as a request to access foo repository in the home directory of user alice. If --user-path=path is specified, the same request is taken as a request to access path/foo repository in the home directory of user alice.
--verbose Log details about the incoming connections and requested files.
--reuseaddr Use SO_REUSEADDR when binding the listening socket. This allows the server to restart without waiting for old connections to time out.
--detach Detach from the shell. Implies --syslog.
--pid-file=<file> Save the process id in file. Ignored when the daemon is run under --inetd.
--user=<user>, --group=<group> Change daemon’s uid and gid before entering the service loop. When only --user is given without --group, the primary group ID for the user is used. The values of the option are given to getpwnam(3) and getgrnam(3) and numeric IDs are not supported.
Giving these options is an error when used with --inetd; use the facility of inet daemon to achieve the same before spawning git daemon if needed.
Like many programs that switch user id, the daemon does not reset environment variables such as $HOME when it runs git programs, e.g. upload-pack and receive-pack. When using this option, you may also want to set and export HOME to point at the home directory of <user> before starting the daemon, and make sure any Git configuration files in that directory are readable by <user>.
--enable=<service>, --disable=<service> Enable/disable the service site-wide per default. Note that a service disabled site-wide can still be enabled per repository if it is marked overridable and the repository enables the service with a configuration item.
--allow-override=<service>, --forbid-override=<service> Allow/forbid overriding the site-wide default with per repository configuration. By default, all the services may be overridden.
--[no-]informative-errors When informative errors are turned on, git-daemon will report more verbose errors to the client, differentiating conditions like "no such repository" from "repository not exported". This is more convenient for clients, but may leak information about the existence of unexported repositories. When informative errors are not enabled, all errors report "access denied" to the client. The default is --no-informative-errors.
--access-hook=<path> Every time a client connects, first run an external command specified by the <path> with service name (e.g. "upload-pack"), path to the repository, hostname (%H), canonical hostname (%CH), IP address (%IP), and TCP port (%P) as its command-line arguments. The external command can decide to decline the service by exiting with a non-zero status (or to allow it by exiting with a zero status). It can also look at the $REMOTE_ADDR and $REMOTE_PORT environment variables to learn about the requestor when making this decision.
The external command can optionally write a single line to its standard output to be sent to the requestor as an error message when it declines the service.
<directory> A directory to add to the whitelist of allowed directories. Unless --strict-paths is specified this will also include subdirectories of each named directory.
These services can be globally enabled/disabled using the command-line options of this command. If finer-grained control is desired (e.g. to allow git archive to be run against only in a few selected repositories the daemon serves), the per-repository configuration file can be used to enable or disable them.
upload-pack This serves git fetch-pack and git ls-remote clients. It is enabled by default, but a repository can disable it by setting daemon.uploadpack configuration item to false.
upload-archive This serves git archive --remote. It is disabled by default, but a repository can enable it by setting daemon.uploadarch configuration item to true.
receive-pack This serves git send-pack clients, allowing anonymous push. It is disabled by default, as there is no authentication in the protocol (in other words, anybody can push anything into the repository, including removal of refs). This is solely meant for a closed LAN setting where everybody is friendly. This service can be enabled by setting daemon.receivepack configuration item to true.
We assume the following in /etc/services
$ grep 9418 /etc/services git             9418/tcp                # Git Version Control System
git daemon as inetd server To set up git daemon as an inetd service that handles any repository under the whitelisted set of directories, /pub/foo and /pub/bar, place an entry like the following into /etc/inetd all on one line:
git stream tcp nowait nobody  /usr/bin/git git daemon --inetd --verbose --export-all /pub/foo /pub/bar
git daemon as inetd server for virtual hosts To set up git daemon as an inetd service that handles repositories for different virtual hosts, www.example.com and www.example.org, place an entry like the following into /etc/inetd all on one line:
git stream tcp nowait nobody /usr/bin/git git daemon --inetd --verbose --export-all --interpolated-path=/pub/%H%D /pub/www.example.org/software /pub/www.example.com/software /software
In this example, the root-level directory /pub will contain a subdirectory for each virtual host name supported. Further, both hosts advertise repositories simply as git://www.example.com/software/repo.git. For pre-1.4.0 clients, a symlink from /software into the appropriate default repository could be made as well.
git daemon as regular daemon for virtual hosts To set up git daemon as a regular, non-inetd service that handles repositories for multiple virtual hosts based on their IP addresses, start the daemon like this:
git daemon --verbose --export-all --interpolated-path=/pub/%IP/%D /pub/192.168.1.200/software /pub/10.10.220.23/software
In this example, the root-level directory /pub will contain a subdirectory for each virtual host IP address supported. Repositories can still be accessed by hostname though, assuming they correspond to these IP addresses.
selectively enable/disable services per repository To enable git archive --remote and disable git fetch against a repository, have the following in the configuration file in the repository (that is the file config next to HEAD, refs and objects).
[daemon] uploadpack = false uploadarch = true
git daemon will set REMOTE_ADDR to the IP address of the client that connected to it, if the IP address is available. REMOTE_ADDR will be available in the environment of hooks called when services are performed.
ANSIWEATHER(1)             BSD General Commands Manual            ANSIWEATHER(1)
ansiweather â€” weather in terminal, with ANSI colors and Unicode symbols
ansiweather [-F] [-l location] [-u system] [-f days] [-a value] [-s value] [-k key] [-w value] [-h value] [-p value] [-d value] [-v value]
ansiweather is a shell script for displaying the current weather conditions in a terminal, with support for ANSI colors and Unicode symbols.
Weather data comes from the OpenWeatherMap free weather API.
-l location Specify location
-u system Specify unit system to use ( metric or imperial )
-f days Toggle forecast mode for the specified number of upcoming days
-F      Toggle forecast mode for the next five days
-a value Toggle ANSI colors display ( true or false )
-s value Toggle symbols display ( true or false )
-k key  Specify OpenWeatherMap API key
-w value Toggle wind data display ( true or false )
-h value Toggle humidity data display ( true or false )
-p value Toggle pressure data display ( true or false )
-d value Toggle daylight data display ( true or false )
-v      Display version
Display forecast using metric units for the next five days (showing symbols and daylight data) for Rzeszow, Poland:
ansiweather -l Rzeszow,PL -u metric -s true -f 5 -d true
ansiweather was written by Frederic Cambus.
RENAME(1)              User Contributed Perl Documentation             RENAME(1)
rename - renames multiple files using perl expressions
rename [-bfilnv] [-B prefix] [-S suffix] [-V method] [-Y prefix] [-z suffix] [--backup] [--basename-prefix=prefix] [--dry-run] [--force] [--help] [--no-stdin] [--interactive] [--just-print] [--link-only] [--prefix=prefix] [--suffix=suffix] [--verbose] [--version-control=method] [--version] perlexpr [files]...
rename renames the filenames supplied according to the rule specified as the first argument.  The argument is a Perl expression which is expected to modify the $_ string for at least some of the filenames specified.  If a given filename is not modified by the expression, it will not be renamed.  If no filenames are given on the command line, filenames will be read via standard input (unless --no-stdin is supplied on the command line).
If a destination file is unwritable, the standard input is a tty, and the -f or --force option is not given, rename prompts the user for whether to overwrite the file.  If the response does not begin with `y' or `Y', the file is skipped.
-b, --backup Make backup files.  That is, when about to overwrite a file, rename the original instead of removing it.  See the -V or --version-control option fo details about how backup file names are determined.
-B prefix, --prefix=prefix Use the simple method to determine backup file names (see the -V method or --version-control=method option), and prepend prefix to a file name when generating its backup file name.
-f, --force Remove existing destination files and never prompt the user.
-h, --help Print a summary of options and exit.
-no-stdin Disable reading of filenames from STDIN. Us it when your shell has nullglob enabled to make sure rename doesn't wait for input.
-i, --interactive Prompt whether to overwrite each destination file that already exists.  If the response does not begin with `y' or `Y', the file is skipped.
-l, --link-only Link files to the new names instead of renaming them. This will keep the original files.
-n, --just-print, --dry-run Do everything but the actual renaming, instead just print the name of each file that would be renamed. When used together with --verbose, also print names of backups (which may or may not be correct depending on previous renaming).
-v, --verbose Print the name of each file before renaming it.
-V method, --version-control=method Use method to determine backup file names.  The method can also be given by the RENAME_VERSION_CONTROL (or if that's not set, the VERSION_CONTROL) environment variable, which is overridden by this option.  This option does not affect whether backup files are made; it affects only the name of any backup files that are made.
The value of method is like the GNU Emacs `version-control' variable; rename also recognize synonyms that are more descriptive.  The valid values are (unique abbreviations are accepted):
existing or nil Make numbered backups of files that already have them, otherwise simple backups. This is the default.
numbered or t Make numbered backups.  The numbered backup file name for F is F.~N~ where N is the version number.
simple or never Make simple backups.  The -B or --prefix, -Y or --basename-prefix, and -z or --suffix options specify the simple backup file name.  If none of these options are given, then a simple backup suffix is used, either the value of SIMPLE_BACKUP_SUFFIX environment variable if set, or ~ otherwise.
--version Print version information on standard output then exit successfully.
-Y prefix, --basename-prefix=prefix Use the simple method to determine backup file names (see the -V method or --version-control=method option), and prefix prefix to the basename of a file name when generating its backup file name. For example, with -Y .del/ the simple backup file name for a/b/foo is a/b/.del/foo.
-z suffix, -S suffix, --suffix=suffix Use the simple method to determine backup file names (see the -V method or --version-control=method option), and append suffix to a file name when generating its backup file name.
To rename all files matching *.bak to strip the extension, you might say
rename 's/\e.bak$//' *.bak
More examples:
rename 's/\.flip$/.flop/'       # rename *.flip to *.flop rename s/flip/flop/             # rename *flip* to *flop* rename 's/^s\.(.*)/$1.X/'       # switch sccs filenames around rename 's/$/.orig/ */*.[ch]'    # add .orig to source files in */ rename 'y/A-Z/a-z/'             # lowercase all filenames in . rename 'y/A-Z/a-z/ if -B'       # same, but just binaries! or even rename chop *~                  # restore all ~ backup files
Two environment variables are used, SIMPLE_BACKUP_SUFFIX and VERSION_CONTROL.  See "OPTIONS".
mv(1) and perl(1)
Peder Stray <pederst@cpan.org>, original script from Larry Wall.
Report any issues at <https://github.com/pstray/rename/issues>.
RUN-MAILCAP(1)                Run Mailcap Programs                RUN-MAILCAP(1)
run-mailcap, view, see, edit, compose, print - execute programs via entries in the mailcap file
run-mailcap --action=ACTION [--option[=value]] [MIME- TYPE:[ENCODING:]]FILE [...]
The see, edit, compose and print versions are just aliases that default to the view, edit, compose, and print actions (respectively).
run-mailcap (or any of its aliases) will use the given action to process each mime-type/file in turn.  Each file is specified as its mime-type, its encoding (e.g. compression), and filename together, separated by colons.  If the mime-type is omitted, an attempt to determine the type is made by trying to match the file's extension with those in the mime.types files.  If no mime-type is found, a last attempt will be done by running the file command, if available.  If the encoding is omitted, it will also be determined from the file's extensions.  Currently supported encodings are gzip (.gz), bzip2 (.bz2), xz (.xz), and compress (.Z).  A filename of "-" can be used to mean "standard input", but then a mime-type must be specified.
Both the user's files (~/.mailcap; ~/.mime.types) and the system files (/etc/mailcap; /etc/mime.types) are searched in turn for information.
EXAMPLES see picture.jpg print output.ps.gz compose text/html:index.htm extract-mail-attachment msg.txt | see image/tiff:gzip:-
OPTIONS All options are in the form --<opt>=<value>.
--action=<action> Performs the specified action on the files.  Valid actions are view, cat (uses only "copiousoutput" rules and sends output to STDOUT) , compose, composetyped, edit and print.  If no action is specified, the action will be determined by how the program was called.
--debug Turns on extra information to find out what is happening.
--nopager Ignores any "copiousoutput" directive and sends output to STDOUT.
--norun Displays the found command without actually executing it.
A temporary copy of the file is opened if the file name matches the Perl regular expression "[^[:alnum:],.:/@%^+=_-]", in order to protect from the injection of shell commands, and to make sure that the name can always be displayed in the current locale.  In addition, the file is opened using its absolute path to prevent the injection of command-line arguments, for instance using file names starting with dashes.
file(1) mailcap(5) mailcap.order(5) update-mime(8)
run-mailcap (and its aliases) was written by Brian White <bcwhite@pobox.com>.
run-mailcap (and its aliases) is in the public domain (the only true "free").
GIT-SETUP(1)                       Git Extras                       GIT-SETUP(1)
git-setup - Set up a git repository
git-setup [<directory>]
Set up a git repository if one doesnÂ´t exist, add all files and make an initial commit.
<directory>
The name of a new directory to setup. By default, the current working directory.
$ git setup path/to/repository
Written by Aggelos Orfanakos <agorf@agorf.gr>
VALAC(1)                          User Commands                         VALAC(1)
valac - compiler that translates Vala source code into C source and header files
valac [OPTION]... [FILE]...
Vala  is  a  programming  language  that  aims  to  bring  modern programming language features to GNOME developers without imposing any additional  runtime requirements  and  without using  a different  ABI compared to applications and libraries written in C.
valac, the Vala compiler, is a self-hosting compiler that translates Vala source code into C source and header files. It uses the GObject type system to create classes and interfaces declared in the Vala source code.
Usage: valac [OPTION?] FILE... - Vala Compiler
Help Options: -?, --help Show help options
Application Options: --vapidir=DIRECTORY... Look for package bindings in DIRECTORY
--girdir=DIRECTORY... Look for .gir files in DIRECTORY
--metadatadir=DIRECTORY... Look for GIR .metadata files in DIRECTORY
--pkg=PACKAGE... Include binding for PACKAGE
--vapi=FILE Output VAPI file name
--library=NAME Library name
--shared-library=NAME Shared library name used in generated gir
--gir=NAME-VERSION.gir GObject-Introspection repository file name
-b, --basedir=DIRECTORY Base source directory
-d, --directory=DIRECTORY Change output directory from current working directory
--version Display version number
--api-version Display API version number
-C, --ccode Output C code
-H, --header=FILE Output C header file
--use-header Use C header file (DEPRECATED AND IGNORED)
--includedir=DIRECTORY Directory used to include the C header file
-h, --internal-header=FILE Output internal C header file
--internal-vapi=FILE Output vapi with internal api
--fast-vapi Output vapi without performing symbol resolution
--use-fast-vapi Use --fast-vapi output during this compile
--vapi-comments Include comments in generated vapi
--deps Write make-style dependency information to this file
--depfile Write make-style external dependency information for build systems to this file
--list-sources Output a list of all source and binding files which are used
--symbols=FILE Output symbols file
-c, --compile Compile but do not link
-o, --output=FILE Place output in file FILE
-g, --debug Produce debug information
--thread Enable multithreading support (DEPRECATED AND IGNORED)
--enable-mem-profiler Enable GLib memory profiler
-D, --define=SYMBOL... Define SYMBOL
--main=SYMBOL... Use SYMBOL as entry point
--nostdpkg Do not include standard packages
--disable-assert Disable assertions
--enable-checking Enable additional run-time checks
--enable-deprecated Enable deprecated features
--hide-internal Hide symbols marked as internal
--enable-experimental Enable experimental features
--disable-warnings Disable warnings
--fatal-warnings Treat warnings as fatal
--disable-since-check Do not check whether used symbols exist in local packages
-k, --keep-going Continue as much as possible after an error
--enable-experimental-non-null Enable experimental enhancements for non-null types
--enable-gobject-tracing Enable GObject creation tracing
--cc=COMMAND Use COMMAND as C compiler command
-X, --Xcc=OPTION... Pass OPTION to the C compiler
--pkg-config=COMMAND Use COMMAND as pkg-config command
--dump-tree=FILE Write code tree to FILE
--save-temps Keep temporary files
--profile=PROFILE Minimum runtime dependency: 'gobject' (default) or 'posix' (minimal libc) gobject enables GLib's GType runtime type system. The runtime environment will usually require libgobject and its small number of dependencies.  posix removes the dependency on GLib and disables the runtime type system. The profile either generates alternative code or errors at compile time if a Vala language feature is used that requires the runtime type system. This is useful for writing code, for example, that targets microcontrollers or for extremely small system utilities or container images. The runtime environment will usually require a small subset of the ISO C standard library.
-q, --quiet Do not print messages to the console
-v, --verbose Print additional messages to the console
--no-color Disable colored output, alias for --color=never
--color=WHEN Enable color output, options are 'always', 'never', or 'auto' When no value is given always is implied. When neither --color or --no-color are declared then --color=auto is used where output is colored when stderr is a terminal.
--target-glib='MAJOR.MINOR', or 'auto' Target version of glib for code generation
--gresources=FILE... XML of gresources
--gresourcesdir=DIRECTORY... Look for resources in DIRECTORY
--enable-version-header Write vala build version in generated files
--disable-version-header Do not write vala build version in generated files
--run-args Arguments passed to directly compiled executable
--abi-stability Enable support for ABI stability This changes the current behaviour to output public members of classes and interfaces the same order as they appear in Vala source.  For libraries is recommended to use --abi-stability to ensure the maintainability of the resulting Application Binary Interface (ABI).  This option is disabled by default for backward compatibility because it can break ABI of existing projects.
https://gitlab.gnome.org/GNOME/vala/issues
https://wiki.gnome.org/Projects/Vala
Interfaces, properties, signals, foreach, lambda expressions, type inference for local variables, generics, non-null types, assisted memory management, exception handling
J??rg Billeter, Raffaele Sandrini, Rico Tzschichholz.
GIT-FETCH(1)                       Git Manual                       GIT-FETCH(1)
git-fetch - Download objects and refs from another repository
git fetch [<options>] [<repository> [<refspec>...]] git fetch [<options>] <group> git fetch --multiple [<options>] [(<repository> | <group>)...] git fetch --all [<options>]
Fetch branches and/or tags (collectively, "refs") from one or more other repositories, along with the objects necessary to complete their histories. Remote-tracking branches are updated (see the description of <refspec> below for ways to control this behavior).
By default, any tag that points into the histories being fetched is also fetched; the effect is to fetch tags that point at branches that you are interested in. This default behavior can be changed by using the --tags or --no-tags options or by configuring remote.<name>.tagOpt. By using a refspec that fetches tags explicitly, you can fetch tags that do not point into branches you are interested in as well.
git fetch can fetch from either a single named repository or URL, or from several repositories at once if <group> is given and there is a remotes.<group> entry in the configuration file. (See git-config(1)).
When no remote is specified, by default the origin remote will be used, unless there’s an upstream branch configured for the current branch.
The names of refs that are fetched, together with the object names they point at, are written to .git/FETCH_HEAD. This information may be used by scripts or other git commands, such as git-pull(1).
--all Fetch all remotes.
-a, --append Append ref names and object names of fetched refs to the existing contents of .git/FETCH_HEAD. Without this option old data in .git/FETCH_HEAD will be overwritten.
--atomic Use an atomic transaction to update local refs. Either all refs are updated, or on error, no refs are updated.
--depth=<depth> Limit fetching to the specified number of commits from the tip of each remote branch history. If fetching to a shallow repository created by git clone with --depth=<depth> option (see git-clone(1)), deepen or shorten the history to the specified number of commits. Tags for the deepened commits are not fetched.
--deepen=<depth> Similar to --depth, except it specifies the number of commits from the current shallow boundary instead of from the tip of each remote branch history.
--shallow-since=<date> Deepen or shorten the history of a shallow repository to include all reachable commits after <date>.
--shallow-exclude=<revision> Deepen or shorten the history of a shallow repository to exclude commits reachable from a specified remote branch or tag. This option can be specified multiple times.
--unshallow If the source repository is complete, convert a shallow repository to a complete one, removing all the limitations imposed by shallow repositories.
If the source repository is shallow, fetch as much as possible so that the current repository has the same history as the source repository.
--update-shallow By default when fetching from a shallow repository, git fetch refuses refs that require updating .git/shallow. This option updates .git/shallow and accept such refs.
--negotiation-tip=<commit|glob> By default, Git will report, to the server, commits reachable from all local refs to find common commits in an attempt to reduce the size of the to-be-received packfile. If specified, Git will only report commits reachable from the given tips. This is useful to speed up fetches when the user knows which local ref is likely to have commits in common with the upstream ref being fetched.
This option may be specified more than once; if so, Git will report commits reachable from any of the given commits.
The argument to this option may be a glob on ref names, a ref, or the (possibly abbreviated) SHA-1 of a commit. Specifying a glob is equivalent to specifying this option multiple times, one for each matching ref name.
See also the fetch.negotiationAlgorithm and push.negotiate configuration variables documented in git-config(1), and the --negotiate-only option below.
--negotiate-only Do not fetch anything from the server, and instead print the ancestors of the provided --negotiation-tip=* arguments, which we have in common with the server.
Internally this is used to implement the push.negotiate option, see git-config(1).
--dry-run Show what would be done, without making any changes.
--[no-]write-fetch-head Write the list of remote refs fetched in the FETCH_HEAD file directly under $GIT_DIR. This is the default. Passing --no-write-fetch-head from the command line tells Git not to write the file. Under --dry-run option, the file is never written.
-f, --force When git fetch is used with <src>:<dst> refspec it may refuse to update the local branch as discussed in the <refspec> part below. This option overrides that check.
-k, --keep Keep downloaded pack.
--multiple Allow several <repository> and <group> arguments to be specified. No <refspec>s may be specified.
--[no-]auto-maintenance, --[no-]auto-gc Run git maintenance run --auto at the end to perform automatic repository maintenance if needed. (--[no-]auto-gc is a synonym.) This is enabled by default.
--[no-]write-commit-graph Write a commit-graph after fetching. This overrides the config setting fetch.writeCommitGraph.
--prefetch Modify the configured refspec to place all refs into the refs/prefetch/ namespace. See the prefetch task in git- maintenance(1).
-p, --prune Before fetching, remove any remote-tracking references that no longer exist on the remote. Tags are not subject to pruning if they are fetched only because of the default tag auto-following or due to a --tags option. However, if tags are fetched due to an explicit refspec (either on the command line or in the remote configuration, for example if the remote was cloned with the --mirror option), then they are also subject to pruning. Supplying --prune-tags is a shorthand for providing the tag refspec.
See the PRUNING section below for more details.
-P, --prune-tags Before fetching, remove any local tags that no longer exist on the remote if --prune is enabled. This option should be used more carefully, unlike --prune it will remove any local references (local tags) that have been created. This option is a shorthand for providing the explicit tag refspec along with --prune, see the discussion about that in its documentation.
-n, --no-tags By default, tags that point at objects that are downloaded from the remote repository are fetched and stored locally. This option disables this automatic tag following. The default behavior for a remote may be specified with the remote.<name>.tagOpt setting. See git-config(1).
--refmap=<refspec> When fetching refs listed on the command line, use the specified refspec (can be given more than once) to map the refs to remote-tracking branches, instead of the values of remote.*.fetch configuration variables for the remote repository. Providing an empty <refspec> to the --refmap option causes Git to ignore the configured refspecs and rely entirely on the refspecs supplied as command-line arguments. See section on "Configured Remote-tracking Branches" for details.
-t, --tags Fetch all tags from the remote (i.e., fetch remote tags refs/tags/* into local tags with the same name), in addition to whatever else would otherwise be fetched. Using this option alone does not subject tags to pruning, even if --prune is used (though tags may be pruned anyway if they are also the destination of an explicit refspec; see --prune).
--recurse-submodules[=yes|on-demand|no] This option controls if and under what conditions new commits of populated submodules should be fetched too. It can be used as a boolean option to completely disable recursion when set to no or to unconditionally recurse into all populated submodules when set to yes, which is the default when this option is used without any value. Use on-demand to only recurse into a populated submodule when the superproject retrieves a commit that updates the submodule’s reference to a commit that isn’t already in the local submodule clone. By default, on-demand is used, unless fetch.recurseSubmodules is set (see git-config(1)).
-j, --jobs=<n> Number of parallel children to be used for all forms of fetching.
If the --multiple option was specified, the different remotes will be fetched in parallel. If multiple submodules are fetched, they will be fetched in parallel. To control them independently, use the config settings fetch.parallel and submodule.fetchJobs (see git-config(1)).
Typically, parallel recursive and multi-remote fetches will be faster. By default fetches are performed sequentially, not in parallel.
--no-recurse-submodules Disable recursive fetching of submodules (this has the same effect as using the --recurse-submodules=no option).
--set-upstream If the remote is fetched successfully, add upstream (tracking) reference, used by argument-less git-pull(1) and other commands. For more information, see branch.<name>.merge and branch.<name>.remote in git-config(1).
--submodule-prefix=<path> Prepend <path> to paths printed in informative messages such as "Fetching submodule foo". This option is used internally when recursing over submodules.
--recurse-submodules-default=[yes|on-demand] This option is used internally to temporarily provide a non-negative default value for the --recurse-submodules option. All other methods of configuring fetch’s submodule recursion (such as settings in gitmodules(5) and git-config(1)) override this option, as does specifying --[no-]recurse-submodules directly.
-u, --update-head-ok By default git fetch refuses to update the head which corresponds to the current branch. This flag disables the check. This is purely for the internal use for git pull to communicate with git fetch, and unless you are implementing your own Porcelain you are not supposed to use it.
--upload-pack <upload-pack> When given, and the repository to fetch from is handled by git fetch-pack, --exec=<upload-pack> is passed to the command to specify non-default path for the command run on the other end.
-q, --quiet Pass --quiet to git-fetch-pack and silence any other internally used git commands. Progress is not reported to the standard error stream.
-o <option>, --server-option=<option> Transmit the given string to the server when communicating using protocol version 2. The given string must not contain a NUL or LF character. The server’s handling of server options, including unknown ones, is server-specific. When multiple --server-option=<option> are given, they are all sent to the other side in the order listed on the command line.
--show-forced-updates By default, git checks if a branch is force-updated during fetch. This can be disabled through fetch.showForcedUpdates, but the --show-forced-updates option guarantees this check occurs. See git- config(1).
--no-show-forced-updates By default, git checks if a branch is force-updated during fetch. Pass --no-show-forced-updates or set fetch.showForcedUpdates to false to skip this check for performance reasons. If used during git-pull the --ff-only option will still check for forced updates before attempting a fast-forward update. See git-config(1).
<repository> The "remote" repository that is the source of a fetch or pull operation. This parameter can be either a URL (see the section GIT URLS below) or the name of a remote (see the section REMOTES below).
<group> A name referring to a list of repositories as the value of remotes.<group> in the configuration file. (See git-config(1)).
<refspec> Specifies which refs to fetch and which local refs to update. When no <refspec>s appear on the command line, the refs to fetch are read from remote.<repository>.fetch variables instead (see CONFIGURED REMOTE-TRACKING BRANCHES below).
The format of a <refspec> parameter is an optional plus +, followed by the source <src>, followed by a colon :, followed by the destination ref <dst>. The colon can be omitted when <dst> is empty. <src> is typically a ref, but it can also be a fully spelled hex object name.
A <refspec> may contain a * in its <src> to indicate a simple pattern match. Such a refspec functions like a glob that matches any ref with the same prefix. A pattern <refspec> must have a * in both the <src> and <dst>. It will map refs to the destination by replacing the * with the contents matched from the source.
If a refspec is prefixed by ^, it will be interpreted as a negative refspec. Rather than specifying which refs to fetch or which local refs to update, such a refspec will instead specify refs to exclude. A ref will be considered to match if it matches at least one positive refspec, and does not match any negative refspec. Negative refspecs can be useful to restrict the scope of a pattern refspec so that it will not include specific refs. Negative refspecs can themselves be pattern refspecs. However, they may only contain a <src> and do not specify a <dst>. Fully spelled out hex object names are also not supported.
tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>; it requests fetching everything up to the given tag.
The remote ref that matches <src> is fetched, and if <dst> is not an empty string, an attempt is made to update the local ref that matches it.
Whether that update is allowed without --force depends on the ref namespace it’s being fetched to, the type of object being fetched, and whether the update is considered to be a fast-forward. Generally, the same rules apply for fetching as when pushing, see the <refspec>...  section of git-push(1) for what those are. Exceptions to those rules particular to git fetch are noted below.
Until Git version 2.20, and unlike when pushing with git-push(1), any updates to refs/tags/* would be accepted without + in the refspec (or --force). When fetching, we promiscuously considered all tag updates from a remote to be forced fetches. Since Git version 2.20, fetching to update refs/tags/* works the same way as when pushing. I.e. any updates will be rejected without + in the refspec (or --force).
Unlike when pushing with git-push(1), any updates outside of refs/{tags,heads}/* will be accepted without + in the refspec (or --force), whether that’s swapping e.g. a tree object for a blob, or a commit for another commit that’s doesn’t have the previous commit as an ancestor etc.
Unlike when pushing with git-push(1), there is no configuration which’ll amend these rules, and nothing like a pre-fetch hook analogous to the pre-receive hook.
As with pushing with git-push(1), all of the rules described above about what’s not allowed as an update can be overridden by adding an the optional leading + to a refspec (or using --force command line option). The only exception to this is that no amount of forcing will make the refs/heads/* namespace accept a non-commit object.