neulab/tldr huggingface dataset:
GNUecho(1)                   General Commands Manual                  GNUecho(1)
echo - echo arguments
echo [options]...
Echo writes its arguments separated by blanks and terminated by a newline on the standard output.  Options to filter and redirect the output are as follows:
-2     generate rhyming couplets from keywords
-3     generate Haiku verse from keywords
-5     generate limerick from keywords
-a     convert ASCII to ASCII
-A     disambiguate sentence structure
-b     generate bureaucratese equivalent (see -x)
-B     issue equivalent C code with bugs fixed
-c     simplify/calculate arithmetic expression(s)
-C     remove copyright notice(s)
-d     define new echo switch map
-D     delete all ownership information from system files
-e     evaluate lisp expression(s)
-E     convert ASCII to Navajo
-f     read input from file
-F     transliterate to french
-g     generate pseudo-revolutionary marxist catch-phrases
-G     prepend GNU manifesto
-h     halt system (reboot suppressed on Suns, Apollos, and VAXen, not supported on NOS-2)
-i     emulate IBM OS/VU (recursive universes not supported)
-I     emulate IBM VTOS 3.7.6 (chronosynclastic infundibulae supported with restrictions documented in IBM VTOS Reference Manual rev 3.2.6)
-J     generate junk mail
-j     justify text (see -b option)
-k     output "echo" software tools
-K     delete privileged accounts
-l     generate legalese equivalent
-L     load echo modules
-M     generate mail
-N     send output to all reachable networks (usable with -J, -K, -h options)
-n     do not add newline to the output
-o     generate obscene text
-O     clean up dirty language
-p     decrypt and print /etc/passwd
-P     port echo to all reachable networks
-P1    oolcay itay
-q     query standard input for arguments
-r     read alternate ".echo" file on start up
-R     change root password to "RMS"
-s     suspend operating system during output (Sun and VAX BSD 4.2 only)
-S     translate to swahili
-T     emulate TCP/IP handler
-t     issue troff output
-u     issue unix philosophy essay
-v     generate reverberating echo
-V     print debugging information
-x     decrypt DES format messages (NSA secret algorithm CX 3.8, not distributed outside continental US)
Echo is useful for producing diagnostics in shell programs and for writing constant data on pipes.  To send diagnostics to the standard error file, do `echo ... 1>&2'.
sv(8)                        System Manager's Manual                       sv(8)
sv - control and manage services monitored by runsv(8)
sv [-v] [-w sec] command services
/etc/init.d/service [-w sec] command
The sv program reports the current status and controls the state of services monitored by the runsv(8) supervisor.
services consists of one or more arguments, each argument naming a directory service used by runsv(8).  If service doesn't start with a dot or slash and doesn't end with a slash, it is searched in the default services directory /etc/service/, otherwise relative to the current directory.
command is one of up, down, status, once, pause, cont, hup, alarm, interrupt, 1, 2, term, kill, or exit, or start, stop, restart, shutdown, force-stop, force-reload, force-restart, force-shutdown.
The sv program can be sym-linked to /etc/init.d/ to provide an LSB init script interface.  The service to be controlled then is specified by the base name of the ``init script''.
status Report the current status of the service, and the appendant log service if available, to standard output.
up     If the service is not running, start it.  If the service stops, restart it.
down   If the service is running, send it the TERM signal, and the CONT signal.  If ./run exits, start ./finish if it exists.  After it stops, do not restart service.
once   If the service is not running, start it.  Do not restart it if it stops.
pause cont hup alarm interrupt quit 1 2 term kill If the service is running, send it the STOP, CONT, HUP, ALRM, INT, QUIT, USR1, USR2, TERM, or KILL signal respectively.
exit   If the service is running, send it the TERM signal, and the CONT signal.  Do not restart the service.  If the service is down, and no log service exists, runsv(8) exits.  If the service is down and a log service exists, runsv(8) closes the standard input of the log service and waits for it to terminate.  If the log service is down, runsv(8) exits.  This command is ignored if it is given to an appendant log service.
sv actually looks only at the first character of these commands.
Commands compatible to LSB init script actions status Same as status.
start  Same as up, but wait up to 7 seconds for the command to take effect.  Then report the status or timeout.  If the script ./check exists in the service directory, sv runs this script to check whether the service is up and available; it's considered to be available if ./check exits with 0.
stop   Same as down, but wait up to 7 seconds for the service to become down.  Then report the status or timeout.
reload Same as hup, and additionally report the status afterwards.
restart Send the commands term, cont, and up to the service, and wait up to 7 seconds for the service to restart.  Then report the status or timeout.  If the script ./check exists in the service directory, sv runs this script to check whether the service is up and available again; it's considered to be available if ./check exits with 0.
shutdown Same as exit, but wait up to 7 seconds for the runsv(8) process to terminate.  Then report the status or timeout.
force-stop Same as down, but wait up to 7 seconds for the service to become down.  Then report the status, and on timeout send the service the kill command.
force-reload Send the service the term and cont commands, and wait up to 7 seconds for the service to restart.  Then report the status, and on timeout send the service the kill command.
force-restart Send the service the term, cont and up commands, and wait up to 7 seconds for the service to restart.  Then report the status, and on timeout send the service the kill command.  If the script ./check exists in the service directory, sv runs this script to check whether the service is up and available again; it's considered to be available if ./check exits with 0.
force-shutdown Same as exit, but wait up to 7 seconds for the runsv(8) process to terminate.  Then report the status, and on timeout send the service the kill command.
try-restart if the service is running, send it the term and cont commands, and wait up to 7 seconds for the service to restart.  Then report the status or timeout.
Additional Commands check  Check for the service to be in the state that's been requested. Wait up to 7 seconds for the service to reach the requested state, then report the status or timeout.  If the requested state of the service is up, and the script ./check exists in the service directory, sv runs this script to check whether the service is up and running; it's considered to be up if ./check exits with 0.
-v     If the command is up, down, term, once, cont, or exit, then wait up to 7 seconds for the command to take effect.  Then report the status or timeout.
-w sec Override the default timeout of 7 seconds with sec seconds.  This option implies -v.
SVDIR  The environment variable $SVDIR overrides the default services directory /etc/service/.
SVWAIT The environment variable $SVWAIT overrides the default 7 seconds to wait for a command to take effect.  It is overridden by the -w option.
sv exits 0, if the command was successfully sent to all services, and, if it was told to wait, the command has taken effect to all services.
For each service that caused an error (e.g. the directory is not controlled by a runsv(8) process, or sv timed out while waiting), sv increases the exit code by one and exits non zero.  The maximum is 99. sv exits 100 on error.
If sv is called with a base name other than sv: it exits 1 on timeout or trouble sending the command; if the command is status, it exits 3 if the service is down, and 4 if the status is unknown; it exits 2 on wrong usage, and 151 on error.
runsv(8), chpst(8), svlogd(8), runsvdir(8), runsvchdir(8), runit(8), runit-init(8)
MOC(1)                          Music On Console                          MOC(1)
MOC - Console audio player
mocp [OPTIONS] [FILE|DIR ...]
MOC is a console audio player with simple ncurses interface.  It supports OGG, WAV, MP3 and other formats.  Just run mocp, go to some directory using the menu and press enter to start playing the file.  The program will automatically play the rest of the files in the directory.
With no options and no file arguments the program begins in current directory, or in MusicDir if the StartInMusicDir option is set in the configuration file.  If you give a directory on the command line, MOC will try to go there.  If a playlist is given, then it is loaded.  With multiple files, playlists or directories, everything will be added to the playlist recursively (including the contents of any playlist given). (Note that relative paths in playlists are resolved with respect to the directory of the playlist, or of the symlink being used to reference it.)
If an option can also be set in the configuration file the command line overrides it (but see the -O option for the list-valued configuration options exception).
-D, --debug Run MOC in debug mode.  The client and server log a lot of information to debug files.  Don't use this; the server log is large.  This is only available if MOC was compiled without --disable-debug.
-S, --server Run only the server and exit.
-F, --foreground Implies -S.  Run the server in foreground and log everything to stdout.
-R NAME[:...], --sound-driver NAME[:...] Use the specified sound driver(s).  They can be OSS, ALSA, JACK, SNDIO or null (for debugging).  Some of the drivers may not have been compiled in.  This option is called SoundDriver in the configuration file.
-m, --music-dir Start in MusicDir (set in the configuration file).  This can be also set in the configuration file as StartInMusicDir.
-q, --enqueue Add files given after command line options to the queue.  Don't start the interface.
-a, --append Append files, directories (recursively) and playlists given after command line options to the playlist.  Don't start the interface.
-c, --clear Clear the playlist.
-p, --play Start playing from the first item on the playlist.
-f, --next Request playing the next song from the server's playlist.
-r, --previous Request playing the previous song from the server's playlist.
-s, --stop Request the server to stop playing.
-x, --exit Bring down the server.
-P, --pause Request the server to pause playing.
-U, --unpause Request the server to resume playing when paused.
-G, --toggle-pause Toggle between play and pause.
-k [+|-]N, --seek [+|-]N Seek forward (positive) or backward (negative) by N seconds in the file currently being played.
-T THEME, --theme THEME Use a theme file.  If the path is not absolute, the file will be searched for in /usr/share/moc/themes/ (depends on installation prefix), ~/.moc/themes/ and the current directory.
-C FILE, --config FILE Use the specified configuration file instead of the default.  As this file can specify commands which invoke other applications MOC will refuse to start if it is not owned by either root or the current user, or if it is writable by anyone other than its owner.
-O NAME[+]=VALUE, --set-option NAME[+]=VALUE Override configuration option NAME with VALUE.  This option can be repeated as many times as needed and the option name is not case sensitive.  Most option values are set before the configuration file is processed (which allows the new values to be picked up by substitutions); however, list-valued options are overridden afterwards (which gives the choice of whether the configured values are replaced or added to).
See the example configuration file (config.example) for a description of the options available.
Examples: -O AutoNext=no -O messagelingertime=1 -O XTerms+=xxt:xwt
Note that MOC does not perform variable substitution as it does for values read from the configuration file.
-M DIR, --moc-dir DIR Use the specified MOC directory instead of the default.  This also causes the configuration file from that directory to be used. This can also be specified in the configuration file using the MOCDir option.
-y, --sync This copy of the interface will synchronize its playlist with other clients.  This option is called SyncPlaylist in the configuration file.
-n, --nosync This copy of the interface will not synchronize its playlist with other clients (see above).
-A, --ascii Use ASCII characters to draw lines.  (This helps on some terminals.)
-i, --info Print the information about the file currently being played.
-Q FORMAT_STRING, --format FORMAT_STRING Print information about the file currently being played using a format string.  Replace string sequences with the actual information:
%state     State %file      File %title     Title %artist    Artist %song      SongTitle %album     Album %tt        TotalTime %tl        TimeLeft %ts        TotalSec %ct        CurrentTime %cs        CurrentSec %b         Bitrate %r         Rate
It is also possible to use variables from the FormatString configuration file option.
-e, --recursively Alias of -a for backward compatibility.
-h, --help Print a list of options with short descriptions and exit.
-V, --version Print the program version and exit.
-v [+|-]N, --volume [+|-]N Adjust the mixer volume.  You can set (-v 50) or adjust (-v +10, -v -10).
-t OPTION[,...], --toggle OPTION[,...] -o OPTION[,...], --on OPTION[,...] -u OPTION[,...], --off OPTION[,...] Followed by a list of identifiers, these will control MOC's playlist options.  Valid identifiers are shuffle, repeat and autonext.  They can be shortened to 's', 'r' and 'n' respectively.
Example: -t shuffle,r,n would toggle shuffle, repeat and autonext all at once.
-j N{s|%}, --jump N{s|%} Jump to some position in the current file.  N is the number of seconds (when followed by an 's') or the percent of total file time (when followed by a '%').
Examples: -j 10s, -j 50%
~/.moc MOC directory for the configuration file, socket, the pid file and other data.
~/.moc/config Configuration file for MOC.  The format is very simple; to see how to use it look at the example configuration file (config.example) distributed with the program.  The example file fully describes all the configuration options, and so is a useful reference when using the -O option.  As this file can specify commands which invoke other applications MOC will refuse to start if it is not owned by either root or the current user, or if it is writable by anyone other than its owner.
~/.moc/themes /usr/share/moc/themes Default directories for the theme files.
/usr/share/moc/decoder_plugins Default directories for the audio decoder plugins.
mocp_client_log mocp_server_log Client and server log files.  These files are created in the directory in which the client and server are started.  (Also see the -D option.)
Command line options that affect the server behaviour (like --sound-driver) are ignored if the server is already running at the time of executing mocp.  The user is not warned about this.
http://moc.daper.net/
Damian Pietras     <daper@daper.net> MOC Maintainer(s)  <mocmaint@daper.net>
GIT-REQUEST-PULL(1)                Git Manual                GIT-REQUEST-PULL(1)
git-request-pull - Generates a summary of pending changes
git request-pull [-p] <start> <url> [<end>]
Generate a request asking your upstream project to pull changes into their tree. The request, printed to the standard output, begins with the branch description, summarizes the changes and indicates from where they can be pulled.
The upstream project is expected to have the commit named by <start> and the output asks it to integrate the changes you made since that commit, up to the commit named by <end>, by visiting the repository named by <url>.
-p Include patch text in the output.
<start> Commit to start at. This names a commit that is already in the upstream history.
<url> The repository URL to be pulled from.
<end> Commit to end at (defaults to HEAD). This names the commit at the tip of the history you are asking to be pulled.
When the repository named by <url> has the commit at a tip of a ref that is different from the ref you have locally, you can use the <local>:<remote> syntax, to have its local name, a colon :, and its remote name.
Imagine that you built your work on your master branch on top of the v1.0 release, and want it to be integrated to the project. First you push that change to your public repository for others to see:
git push https://git.ko.xz/project master
Then, you run this command:
git request-pull v1.0 https://git.ko.xz/project master
which will produce a request to the upstream, summarizing the changes between the v1.0 release and your master, to pull it from your public repository.
If you pushed your change to a branch whose name is different from the one you have locally, e.g.
git push https://git.ko.xz/project master:for-linus
then you can ask that to be pulled with
git request-pull v1.0 https://git.ko.xz/project master:for-linus
SSHFS(1)                          User Commands                         SSHFS(1)
SSHFS - filesystem client based on SSH
To mount a filesystem:
sshfs [user@]host:[dir] mountpoint [options]
If host is a numeric IPv6 address, it needs to be enclosed in square brackets.
To unmount it:
fusermount3 -u mountpoint   # Linux umount mountpoint           # OS X, FreeBSD
SSHFS allows you to mount a remote filesystem using SSH (more precisely, the SFTP subsystem). Most SSH servers support and enable this SFTP access by default, so SSHFS is very simple to use - there's nothing to do on the server-side.
By default, file permissions are ignored by SSHFS. Any user that can access the filesystem will be able to perform any operation that the remote server permits - based on the credentials that were used to connect to the server. If this is undesired, local permission checking can be enabled with -o default_permissions.
By default, only the mounting user will be able to access the filesystem. Access for other users can be enabled by passing -o allow_other. In this case you most likely also want to use -o default_permissions.
It is recommended to run SSHFS as regular user (not as root).  For this to work the mountpoint must be owned by the user.  If username is omitted SSHFS will use the local username. If the directory is omitted, SSHFS will mount the (remote) home directory.  If you need to enter a password sshfs will ask for it (actually it just runs ssh which ask for the password if needed).
-o opt,[opt...] mount options, see below for details. A a variety of SSH options can be given here as well, see the manual pages for sftp(1) and ssh_config(5).
-h, --help print help and exit.
-V, --version print version information and exit.
-d, --debug print debugging information.
-p PORT equivalent to '-o port=PORT'
-f     do not daemonize, stay in foreground.
-s     Single threaded operation.
-C     equivalent to '-o compression=yes'
-F ssh_configfile specifies alternative ssh configuration file
-1     equivalent to '-o ssh_protocol=1'
-o reconnect automatically reconnect to server if connection is interrupted. Attempts to access files that were opened before the reconnection will give errors and need to be re-opened.
-o delay_connect Don't immediately connect to server, wait until mountpoint is first accessed.
-o sshfs_sync synchronous writes. This will slow things down, but may be useful in some situations.
-o no_readahead Only read exactly the data that was requested, instead of speculatively reading more to anticipate the next read request.
-o sync_readdir synchronous readdir. This will slow things down, but may be useful in some situations.
-o workaround=LIST Enable the specified workaround. See the Caveats section below for some additional information. Possible values are:
rename Emulate overwriting an existing file by deleting and renaming.
renamexdev Make rename fail with EXDEV instead of the default EPERM to allow moving files across remote filesystems.
truncate Work around servers that don't support truncate by coping the whole file, truncating it locally, and sending it back.
fstat  Work around broken servers that don't support fstat() by using stat instead.
buflimit Work around OpenSSH "buffer fillup" bug.
createmode Work around broken servers that produce an error when passing a non-zero mode to create, by always passing a mode of 0.
-o idmap=TYPE How to map remote UID/GIDs to local values. Possible values are:
none   no translation of the ID space (default).
user   map the UID/GID of the remote user to UID/GID of the mounting user.
file   translate UIDs/GIDs based upon the contents of --uidfile and --gidfile.
-o uidfile=FILE file containing username:uid mappings for -o idmap=file
-o gidfile=FILE file containing groupname:gid mappings for -o idmap=file
-o nomap=TYPE with idmap=file, how to handle missing mappings:
ignore don't do any re-mapping
error  return an error (default)
-o ssh_command=CMD execute CMD instead of 'ssh'
-o ssh_protocol=N ssh protocol to use (default: 2)
-o sftp_server=SERV path to sftp server or subsystem (default: sftp)
-o directport=PORT directly connect to PORT bypassing ssh
-o passive communicate over stdin and stdout bypassing network. Useful for mounting local filesystem on the remote side.  An example using dpipe command would be dpipe /usr/lib/openssh/sftp-server = ssh RemoteHostname sshfs :/directory/to/be/shared ~/mnt/src -o passive
-o disable_hardlink With this option set, attempts to call link(2) will fail with error code ENOSYS.
-o transform_symlinks transform absolute symlinks on remote side to relative symlinks. This means that if e.g. on the server side /foo/bar/com is a symlink to /foo/blub, SSHFS will transform the link target to ../blub on the client side.
-o follow_symlinks follow symlinks on the server, i.e. present them as regular files on the client. If a symlink is dangling (i.e, the target does not exist) the behavior depends on the remote server - the entry may appear as a symlink on the client, or it may appear as a regular file that cannot be accessed.
-o no_check_root don't check for existence of 'dir' on server
-o password_stdin read password from stdin (only for pam_mount!)
-o dir_cache=BOOL Enables (yes) or disables (no) the SSHFS directory cache.  The directory cache holds the names of directory entries. Enabling it allows readdir(3) system calls to be processed without network access.
-o dcache_max_size=N sets the maximum size of the directory cache.
-o dcache_timeout=N sets timeout for directory cache in seconds.
-o dcache_{stat,link,dir}_timeout=N sets separate timeout for {attributes, symlinks, names} in  the directory cache.
-o dcache_clean_interval=N sets the interval for automatic cleaning of the directory cache.
-o dcache_min_clean_interval=N sets the interval for forced cleaning of the directory cache when full.
-o direct_io This option disables the use of page cache (file content cache) in the kernel for this filesystem.  This has several affects:
1. Each read() or write() system call will initiate one or more read or write operations, data will not be cached in the kernel.
2. The return value of the read() and write() system calls will correspond to the return values of the read and write operations. This is useful for example if the file size is not known in advance (before reading it).  e.g. /proc filesystem
-o max_conns=N sets the maximum number of simultaneous SSH connections to use. Each connection is established with a separate SSH process.  The primary purpose of this feature is to improve the responsiveness of the file system during large file transfers. When using more than once connection, the password_stdin and passive options can not be used, and the buflimit workaround is not supported.
In addition, SSHFS accepts several options common to all FUSE file systems. These are described in the mount.fuse manpage (look for "general", "libfuse specific", and "high-level API" options).
CAVEATS / WORKAROUNDS Hardlinks If the SSH server supports the hardlinks extension, SSHFS will allow you to create hardlinks. However, hardlinks will always appear as individual files when seen through an SSHFS mount, i.e. they will appear to have different inodes and an st_nlink value of 1.
Rename Some SSH servers do not support atomically overwriting the destination when renaming a file. In this case you will get an error when you attempt to rename a file and the destination already exists. A workaround is to first remove the destination file, and then do the rename. SSHFS can do this automatically if you call it with -o workaround=rename. However, in this case it is still possible that someone (or something) recreates the destination file after SSHFS has removed it, but before SSHFS had the time to rename the old file. In this case, the rename will still fail.
Permission denied when moving files across remote filesystems Most SFTP servers return only a generic "failure" when failing to rename across filesystem boundaries (EXDEV).  sshfs normally converts this generic failure to a permission denied error (EPERM).  If the option -o workaround=renamexdev is given, generic failures will be considered EXDEV errors which will make programs like mv(1) attempt to actually move the file after the failed rename.
SSHFS hangs for no apparent reason In some cases, attempts to access the SSHFS mountpoint may freeze if no filesystem activity has occured for some time. This is typically caused by the SSH connection being dropped because of inactivity without SSHFS being informed about that. As a workaround, you can try to mount with -o ServerAliveInterval=15. This will force the SSH connection to stay alive even if you have no activity.
SSHFS hangs after the connection was interrupted By default, network operations in SSHFS run without timeouts, mirroring the default behavior of SSH itself. As a consequence, if the connection to the remote host is interrupted (e.g. because a network cable was removed), operations on files or directories under the mountpoint will block until the connection is either restored or closed altogether (e.g. manually).  Applications that try to access such files or directories will generally appear to "freeze" when this happens.
If it is acceptable to discard data being read or written, a quick workaround is to kill the responsible sshfs process, which will make any blocking operations on the mounted filesystem error out and thereby "unfreeze" the relevant applications. Note that force unmounting with fusermount -zu, on the other hand, does not help in this case and will leave read/write operations in the blocking state.
For a more automatic solution, one can use the -o ServerAliveInterval=15 option mentioned above, which will drop the connection after not receiving a response for 3 * 15 = 45 seconds from the remote host. By also supplying -o reconnect, one can ensure that the connection is re-established as soon as possible afterwards. As before, this will naturally lead to loss of data that was in the process of being read or written at the time when the connection was interrupted.
MOUNTING FROM /ETC/FSTAB To mount an SSHFS filesystem from /etc/fstab, simply use sshfs` as the file system type. (For backwards compatibility, you may also use ``fuse.sshfs).
The mount.fuse(8) manpage.
If you need help, please ask on the <fuse-sshfs@lists.sourceforge.net> mailing list (subscribe at https://lists.sourceforge.net/lists/listinfo/fuse-sshfs).
Please report any bugs on the GitHub issue tracker at https://github.com/libfuse/libfuse/issues.
SSHFS is currently maintained by Nikolaus Rath <Nikolaus@rath.org>, and was created by Miklos Szeredi <miklos@szeredi.hu>.
This man page was originally written by Bartosz Fenski <fenio@debian.org> for the Debian GNU/Linux distribution (but it may be used by others).
VIEWNIOR(1)                  General Commands Manual                 VIEWNIOR(1)
viewnior - simple, fast and elegant image viewer
viewnior [OPTIONS] [FILES|FOLDERS]...
Viewnior is an image viewer program. Created to be simple, fast and elegant. It's minimalistic interface provides more screenspace for your images.
--slideshow Start in slideshow
--fullscreen Start in full screen mode
-?, --help Show this help and exit
--version Show version information and exit
Website: http://siyanpanayotov.com/project/viewnior/
Viewnior was written by Siyan Panayotov <contact@siyanpanayotov.com>.
This manual page was written by Siyan Panayotov <contact@siyanpanayotov.com>.
GIT-DIFF(1)                        Git Manual                        GIT-DIFF(1)
git-diff - Show changes between commits, commit and working tree, etc
git diff [<options>] [<commit>] [--] [<path>...] git diff [<options>] --cached [--merge-base] [<commit>] [--] [<path>...] git diff [<options>] [--merge-base] <commit> [<commit>...] <commit> [--] [<path>...] git diff [<options>] <commit>...<commit> [--] [<path>...] git diff [<options>] <blob> <blob> git diff [<options>] --no-index [--] <path> <path>
Show changes between the working tree and the index or a tree, changes between the index and a tree, changes between two trees, changes resulting from a merge, changes between two blob objects, or changes between two files on disk.
git diff [<options>] [--] [<path>...] This form is to view the changes you made relative to the index (staging area for the next commit). In other words, the differences are what you could tell Git to further add to the index but you still haven’t. You can stage these changes by using git-add(1).
git diff [<options>] --no-index [--] <path> <path> This form is to compare the given two paths on the filesystem. You can omit the --no-index option when running the command in a working tree controlled by Git and at least one of the paths points outside the working tree, or when running the command outside a working tree controlled by Git. This form implies --exit-code.
git diff [<options>] --cached [--merge-base] [<commit>] [--] [<path>...] This form is to view the changes you staged for the next commit relative to the named <commit>. Typically you would want comparison with the latest commit, so if you do not give <commit>, it defaults to HEAD. If HEAD does not exist (e.g. unborn branches) and <commit> is not given, it shows all staged changes. --staged is a synonym of --cached.
If --merge-base is given, instead of using <commit>, use the merge base of <commit> and HEAD.  git diff --cached --merge-base A is equivalent to git diff --cached $(git merge-base A HEAD).
git diff [<options>] [--merge-base] <commit> [--] [<path>...] This form is to view the changes you have in your working tree relative to the named <commit>. You can use HEAD to compare it with the latest commit, or a branch name to compare with the tip of a different branch.
If --merge-base is given, instead of using <commit>, use the merge base of <commit> and HEAD.  git diff --merge-base A is equivalent to git diff $(git merge-base A HEAD).
git diff [<options>] [--merge-base] <commit> <commit> [--] [<path>...] This is to view the changes between two arbitrary <commit>.
If --merge-base is given, use the merge base of the two commits for the "before" side.  git diff --merge-base A B is equivalent to git diff $(git merge-base A B) B.
git diff [<options>] <commit> <commit>... <commit> [--] [<path>...] This form is to view the results of a merge commit. The first listed <commit> must be the merge itself; the remaining two or more commits should be its parents. A convenient way to produce the desired set of revisions is to use the ^@ suffix. For instance, if master names a merge commit, git diff master master^@ gives the same combined diff as git show master.
git diff [<options>] <commit>..<commit> [--] [<path>...] This is synonymous to the earlier form (without the ..) for viewing the changes between two arbitrary <commit>. If <commit> on one side is omitted, it will have the same effect as using HEAD instead.
git diff [<options>] <commit>...<commit> [--] [<path>...] This form is to view the changes on the branch containing and up to the second <commit>, starting at a common ancestor of both <commit>. git diff A...B is equivalent to git diff $(git merge-base A B) B. You can omit any one of <commit>, which has the same effect as using HEAD instead.
Just in case you are doing something exotic, it should be noted that all of the <commit> in the above description, except in the --merge-base case and in the last two forms that use .. notations, can be any <tree>.
For a more complete list of ways to spell <commit>, see "SPECIFYING REVISIONS" section in gitrevisions(7). However, "diff" is about comparing two endpoints, not ranges, and the range notations (<commit>..<commit> and <commit>...<commit>) do not mean a range as defined in the "SPECIFYING RANGES" section in gitrevisions(7).
git diff [<options>] <blob> <blob> This form is to view the differences between the raw contents of two blob objects.
-p, -u, --patch Generate patch (see section on generating patches). This is the default.
-s, --no-patch Suppress diff output. Useful for commands like git show that show the patch by default, or to cancel the effect of --patch.
-U<n>, --unified=<n> Generate diffs with <n> lines of context instead of the usual three. Implies --patch.
--raw Generate the diff in raw format.
--patch-with-raw Synonym for -p --raw.
--patch-with-stat Synonym for -p --stat.
-z When --raw, --numstat, --name-only or --name-status has been given, do not munge pathnames and use NULs as output field terminators.
Without this option, pathnames with "unusual" characters are quoted as explained for the configuration variable core.quotePath (see git- config(1)).
--name-only Show only names of changed files. The file names are often encoded in UTF-8. For more information see the discussion about encoding in the git-log(1) manual page.
--name-status Show only names and status of changed files. See the description of the --diff-filter option on what the status letters mean. Just like --name-only the file names are often encoded in UTF-8.
--submodule[=<format>] Specify how differences in submodules are shown. When specifying --submodule=short the short format is used. This format just shows the names of the commits at the beginning and end of the range. When --submodule or --submodule=log is specified, the log format is used. This format lists the commits in the range like git-submodule(1) summary does. When --submodule=diff is specified, the diff format is used. This format shows an inline diff of the changes in the submodule contents between the commit range. Defaults to diff.submodule or the short format if the config option is unset.
--color[=<when>] Show colored diff.  --color (i.e. without =<when>) is the same as --color=always.  <when> can be one of always, never, or auto. It can be changed by the color.ui and color.diff configuration settings.
--no-color Turn off colored diff. This can be used to override configuration settings. It is the same as --color=never.
--color-moved[=<mode>] Moved lines of code are colored differently. It can be changed by the diff.colorMoved configuration setting. The <mode> defaults to no if the option is not given and to zebra if the option with no mode is given. The mode must be one of:
no Moved lines are not highlighted.
default Is a synonym for zebra. This may change to a more sensible mode in the future.
plain Any line that is added in one location and was removed in another location will be colored with color.diff.newMoved. Similarly color.diff.oldMoved will be used for removed lines that are added somewhere else in the diff. This mode picks up any moved line, but it is not very useful in a review to determine if a block of code was moved without permutation.
blocks Blocks of moved text of at least 20 alphanumeric characters are detected greedily. The detected blocks are painted using either the color.diff.{old,new}Moved color. Adjacent blocks cannot be told apart.
zebra Blocks of moved text are detected as in blocks mode. The blocks are painted using either the color.diff.{old,new}Moved color or color.diff.{old,new}MovedAlternative. The change between the two colors indicates that a new block was detected.
dimmed-zebra Similar to zebra, but additional dimming of uninteresting parts of moved code is performed. The bordering lines of two adjacent blocks are considered interesting, the rest is uninteresting. dimmed_zebra is a deprecated synonym.
--no-color-moved Turn off move detection. This can be used to override configuration settings. It is the same as --color-moved=no.
--color-moved-ws=<modes> This configures how whitespace is ignored when performing the move detection for --color-moved. It can be set by the diff.colorMovedWS configuration setting. These modes can be given as a comma separated list:
no Do not ignore whitespace when performing move detection.
ignore-space-at-eol Ignore changes in whitespace at EOL.
ignore-space-change Ignore changes in amount of whitespace. This ignores whitespace at line end, and considers all other sequences of one or more whitespace characters to be equivalent.
ignore-all-space Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none.
allow-indentation-change Initially ignore any whitespace in the move detection, then group the moved code blocks only into a block if the change in whitespace is the same per line. This is incompatible with the other modes.
--no-color-moved-ws Do not ignore whitespace when performing move detection. This can be used to override configuration settings. It is the same as --color-moved-ws=no.
--word-diff[=<mode>] Show a word diff, using the <mode> to delimit changed words. By default, words are delimited by whitespace; see --word-diff-regex below. The <mode> defaults to plain, and must be one of:
color Highlight changed words using only colors. Implies --color.
plain Show words as [-removed-] and {+added+}. Makes no attempts to escape the delimiters if they appear in the input, so the output may be ambiguous.
porcelain Use a special line-based format intended for script consumption. Added/removed/unchanged runs are printed in the usual unified diff format, starting with a +/-/` ` character at the beginning of the line and extending to the end of the line. Newlines in the input are represented by a tilde ~ on a line of its own.
none Disable word diff again.
Note that despite the name of the first mode, color is used to highlight the changed parts in all modes if enabled.
--word-diff-regex=<regex> Use <regex> to decide what a word is, instead of considering runs of non-whitespace to be a word. Also implies --word-diff unless it was already enabled.
Every non-overlapping match of the <regex> is considered a word. Anything between these matches is considered whitespace and ignored(!) for the purposes of finding differences. You may want to append |[^[:space:]] to your regular expression to make sure that it matches all non-whitespace characters. A match that contains a newline is silently truncated(!) at the newline.
For example, --word-diff-regex=.  will treat each character as a word and, correspondingly, show differences character by character.
The regex can also be set via a diff driver or configuration option, see gitattributes(5) or git-config(1). Giving it explicitly overrides any diff driver or configuration setting. Diff drivers override configuration settings.
--color-words[=<regex>] Equivalent to --word-diff=color plus (if a regex was specified) --word-diff-regex=<regex>.
--check Warn if changes introduce conflict markers or whitespace errors. What are considered whitespace errors is controlled by core.whitespace configuration. By default, trailing whitespaces (including lines that consist solely of whitespaces) and a space character that is immediately followed by a tab character inside the initial indent of the line are considered whitespace errors. Exits with non-zero status if problems are found. Not compatible with --exit-code.
--ws-error-highlight=<kind> Highlight whitespace errors in the context, old or new lines of the diff. Multiple values are separated by comma, none resets previous values, default reset the list to new and all is a shorthand for old,new,context. When this option is not given, and the configuration variable diff.wsErrorHighlight is not set, only whitespace errors in new lines are highlighted. The whitespace errors are colored with color.diff.whitespace.
--binary In addition to --full-index, output a binary diff that can be applied with git-apply. Implies --patch.
--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]] Select only files that are Added (A), Copied (C), Deleted (D), Modified (M), Renamed (R), have their type (i.e. regular file, symlink, submodule, ...) changed (T), are Unmerged (U), are Unknown (X), or have had their pairing Broken (B). Any combination of the filter characters (including none) can be used. When * (All-or-none) is added to the combination, all paths are selected if there is any file that matches other criteria in the comparison; if there is no file that matches other criteria, nothing is selected.
Also, these upper-case letters can be downcased to exclude. E.g. --diff-filter=ad excludes added and deleted paths.
Note that not all diffs can feature all types. For instance, diffs from the index to the working tree can never have Added entries (because the set of paths included in the diff is limited by what is in the index). Similarly, copied and renamed entries cannot appear if detection for those types is disabled.
-S<string> Look for differences that change the number of occurrences of the specified string (i.e. addition/deletion) in a file. Intended for the scripter’s use.
It is useful when you’re looking for an exact block of code (like a struct), and want to know the history of that block since it first came into being: use the feature iteratively to feed the interesting block in the preimage back into -S, and keep going until you get the very first version of the block.
Binary files are searched as well.
-G<regex> Look for differences whose patch text contains added/removed lines that match <regex>.
To illustrate the difference between -S<regex> --pickaxe-regex and -G<regex>, consider a commit with the following diff in the same file:
+    return frotz(nitfol, two->ptr, 1, 0); ... -    hit = frotz(nitfol, mf2.ptr, 1, 0);
While git log -G"frotz\(nitfol" will show this commit, git log -S"frotz\(nitfol" --pickaxe-regex will not (because the number of occurrences of that string did not change).
Unless --text is supplied patches of binary files without a textconv filter will be ignored.
See the pickaxe entry in gitdiffcore(7) for more information.
--find-object=<object-id> Look for differences that change the number of occurrences of the specified object. Similar to -S, just the argument is different in that it doesn’t search for a specific string but for a specific object id.
The object can be a blob or a submodule commit. It implies the -t option in git-log to also find trees.
--pickaxe-all When -S or -G finds a change, show all the changes in that changeset, not just the files that contain the change in <string>.
--pickaxe-regex Treat the <string> given to -S as an extended POSIX regular expression to match.
-R Swap two inputs; that is, show differences from index or on-disk file to tree contents.
--exit-code Make the program exit with codes similar to diff(1). That is, it exits with 1 if there were differences and 0 means no differences.
--quiet Disable all output of the program. Implies --exit-code.
-1 --base, -2 --ours, -3 --theirs Compare the working tree with the "base" version (stage #1), "our branch" (stage #2) or "their branch" (stage #3). The index contains these stages only for unmerged entries i.e. while resolving conflicts. See git-read-tree(1) section "3-Way Merge" for detailed information.
-0 Omit diff output for unmerged entries and just show "Unmerged". Can be used only when comparing the working tree with the index.
<path>... The <paths> parameters, when given, are used to limit the diff to the named paths (you can give directory names and get diff for all files under them).
The raw output format from "git-diff-index", "git-diff-tree", "git-diff-files" and "git diff --raw" are very similar.
These commands all compare two sets of things; what is compared differs:
git-diff-index <tree-ish> compares the <tree-ish> and the files on the filesystem.
git-diff-index --cached <tree-ish> compares the <tree-ish> and the index.
git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...] compares the trees named by the two arguments.
git-diff-files [<pattern>...] compares the index and the files on the filesystem.
The "git-diff-tree" command begins its output by printing the hash of what is being compared. After that, all the commands print one output line per changed file.
An output line is formatted this way:
in-place edit  :100644 100644 bcd1234 0123456 M file0 copy-edit      :100644 100644 abcd123 1234567 C68 file1 file2 rename-edit    :100644 100644 abcd123 1234567 R86 file1 file3 create         :000000 100644 0000000 1234567 A file4 delete         :100644 000000 1234567 0000000 D file5 unmerged       :000000 000000 0000000 0000000 U file6
That is, from the left to the right:
1. a colon.
2. mode for "src"; 000000 if creation or unmerged.
3. a space.
4. mode for "dst"; 000000 if deletion or unmerged.
5. a space.
6. sha1 for "src"; 0{40} if creation or unmerged.
7. a space.
8. sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree".
9. a space.
10. status, followed by optional "score" number.
11. a tab or a NUL when -z option is used.
12. path for "src"
13. a tab or a NUL when -z option is used; only exists for C or R.
14. path for "dst"; only exists for C or R.
15. an LF or a NUL when -z option is used, to terminate the record.
Possible status letters are:
•   A: addition of a file
•   C: copy of a file into a new one
•   D: deletion of a file
•   M: modification of the contents or mode of a file
•   R: renaming of a file
•   T: change in the type of the file (regular file, symbolic link or submodule)
•   U: file is unmerged (you must complete the merge before it can be committed)
•   X: "unknown" change type (most probably a bug, please report it)
Status letters C and R are always followed by a score (denoting the percentage of similarity between the source and target of the move or copy). Status letter M may be followed by a score (denoting the percentage of dissimilarity) for file rewrites.
<sha1> is shown as all 0’s if a file is new on the filesystem and it is out of sync with the index.
:100644 100644 5be4a4a 0000000 M file.c
"git-diff-tree", "git-diff-files" and "git-diff --raw" can take -c or --cc option to generate diff output also for merge commits. The output differs from the format described above in the following way:
1. there is a colon for each parent
2. there are more "src" modes and "src" sha1
3. status is concatenated status characters for each parent
4. no optional "score" number
5. tab-separated pathname(s) of the file
For -c and --cc, only the destination or final path is shown even if the file was renamed on any side of history. With --combined-all-paths, the name of the path in each parent is shown followed by the name of the path in the merge commit.
Examples for -c and --cc without --combined-all-paths:
::100644 100644 100644 fabadb8 cc95eb0 4866510 MM       desc.c ::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM       bar.sh ::100644 100644 100644 e07d6c5 9042e82 ee91881 RR       phooey.c
Examples when --combined-all-paths added to either -c or --cc:
::100644 100644 100644 fabadb8 cc95eb0 4866510 MM       desc.c  desc.c  desc.c ::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM       foo.sh  bar.sh  bar.sh ::100644 100644 100644 e07d6c5 9042e82 ee91881 RR       fooey.c fuey.c  phooey.c
Note that combined diff lists only files which were modified from all parents.
GENERATING PATCH TEXT WITH -P Running git-diff(1), git-log(1), git-show(1), git-diff-index(1), git- diff-tree(1), or git-diff-files(1) with the -p option produces patch text. You can customize the creation of patch text via the GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables (see git(1)), and the diff attribute (see gitattributes(5)).
What the -p option produces is slightly different from the traditional diff format:
1. It is preceded with a "git diff" header that looks like this:
diff --git a/file1 b/file2
The a/ and b/ filenames are the same unless rename/copy is involved. Especially, even for a creation or a deletion, /dev/null is not used in place of the a/ or b/ filenames.