diff --git a/external/docs/asciidoc/73ae4b8924e2c768a0a6ba30c01b634b977ea780 b/external/docs/asciidoc/73ae4b8924e2c768a0a6ba30c01b634b977ea780 new file mode 100644 index 0000000000..844f560706 --- /dev/null +++ b/external/docs/asciidoc/73ae4b8924e2c768a0a6ba30c01b634b977ea780 @@ -0,0 +1,1733 @@ +git(1) +====== + +NAME +---- +git - the stupid content tracker + + +SYNOPSIS +-------- +[verse] +'git' [-v | --version] [-h | --help] [-C ] [-c =] + [--exec-path[=]] [--html-path] [--man-path] [--info-path] + [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch] + [--no-optional-locks] [--no-advice] [--bare] [--git-dir=] + [--work-tree=] [--namespace=] [--config-env==] + [] + +DESCRIPTION +----------- +Git is a fast, scalable, distributed revision control system with an +unusually rich command set that provides both high-level operations +and full access to internals. + +See linkgit:gittutorial[7] to get started, then see +linkgit:giteveryday[7] for a useful minimum set of +commands. The link:/docs/user-manual[Git User's Manual] has a more +in-depth introduction. + +After you mastered the basic concepts, you can come back to this +page to learn what commands Git offers. You can learn more about +individual Git commands with "git help command". linkgit:gitcli[7] +manual page gives you an overview of the command-line command syntax. + +A formatted and hyperlinked copy of the latest Git documentation +can be viewed at https://git.github.io/htmldocs/git.html +or https://git-scm.com/docs. + + +OPTIONS +------- +-v:: +--version:: + Prints the Git suite version that the 'git' program came from. ++ +This option is internally converted to `git version ...` and accepts +the same options as the linkgit:git-version[1] command. If `--help` is +also given, it takes precedence over `--version`. + +-h:: +--help:: + Prints the synopsis and a list of the most commonly used + commands. If the option `--all` or `-a` is given then all + available commands are printed. If a Git command is named this + option will bring up the manual page for that command. ++ +Other options are available to control how the manual page is +displayed. See linkgit:git-help[1] for more information, +because `git --help ...` is converted internally into `git +help ...`. + +-C :: + Run as if git was started in '' instead of the current working + directory. When multiple `-C` options are given, each subsequent + non-absolute `-C ` is interpreted relative to the preceding `-C + `. If '' is present but empty, e.g. `-C ""`, then the + current working directory is left unchanged. ++ +This option affects options that expect path name like `--git-dir` and +`--work-tree` in that their interpretations of the path names would be +made relative to the working directory caused by the `-C` option. For +example the following invocations are equivalent: + + git --git-dir=a.git --work-tree=b -C c status + git --git-dir=c/a.git --work-tree=c/b status + +-c =:: + Pass a configuration parameter to the command. The value + given will override values from configuration files. + The is expected in the same format as listed by + 'git config' (subkeys separated by dots). ++ +Note that omitting the `=` in `git -c foo.bar ...` is allowed and sets +`foo.bar` to the boolean true value (just like `[foo]bar` would in a +config file). Including the equals but with an empty value (like `git -c +foo.bar= ...`) sets `foo.bar` to the empty string which `git config +--type=bool` will convert to `false`. + +--config-env==:: + Like `-c =`, give configuration variable + '' a value, where is the name of an + environment variable from which to retrieve the value. Unlike + `-c` there is no shortcut for directly setting the value to an + empty string, instead the environment variable itself must be + set to the empty string. It is an error if the `` does not exist + in the environment. `` may not contain an equals sign + to avoid ambiguity with `` containing one. ++ +This is useful for cases where you want to pass transitory +configuration options to git, but are doing so on operating systems +where other processes might be able to read your command line +(e.g. `/proc/self/cmdline`), but not your environment +(e.g. `/proc/self/environ`). That behavior is the default on +Linux, but may not be on your system. ++ +Note that this might add security for variables such as +`http.extraHeader` where the sensitive information is part of +the value, but not e.g. `url..insteadOf` where the +sensitive information can be part of the key. + +--exec-path[=]:: + Path to wherever your core Git programs are installed. + This can also be controlled by setting the GIT_EXEC_PATH + environment variable. If no path is given, 'git' will print + the current setting and then exit. + +--html-path:: + Print the path, without trailing slash, where Git's HTML + documentation is installed and exit. + +--man-path:: + Print the manpath (see `man(1)`) for the man pages for + this version of Git and exit. + +--info-path:: + Print the path where the Info files documenting this + version of Git are installed and exit. + +-p:: +--paginate:: + Pipe all output into 'less' (or if set, $PAGER) if standard + output is a terminal. This overrides the `pager.` + configuration options (see the "Configuration Mechanism" section + below). + +-P:: +--no-pager:: + Do not pipe Git output into a pager. + +--git-dir=:: + Set the path to the repository (".git" directory). This can also be + controlled by setting the `GIT_DIR` environment variable. It can be + an absolute path or relative path to current working directory. ++ +Specifying the location of the ".git" directory using this +option (or `GIT_DIR` environment variable) turns off the +repository discovery that tries to find a directory with +".git" subdirectory (which is how the repository and the +top-level of the working tree are discovered), and tells Git +that you are at the top level of the working tree. If you +are not at the top-level directory of the working tree, you +should tell Git where the top-level of the working tree is, +with the `--work-tree=` option (or `GIT_WORK_TREE` +environment variable) ++ +If you just want to run git as if it was started in `` then use +`git -C `. + +--work-tree=:: + Set the path to the working tree. It can be an absolute path + or a path relative to the current working directory. + This can also be controlled by setting the GIT_WORK_TREE + environment variable and the core.worktree configuration + variable (see core.worktree in linkgit:git-config[1] for a + more detailed discussion). + +--namespace=:: + Set the Git namespace. See linkgit:gitnamespaces[7] for more + details. Equivalent to setting the `GIT_NAMESPACE` environment + variable. + +--bare:: + Treat the repository as a bare repository. If GIT_DIR + environment is not set, it is set to the current working + directory. + +--no-replace-objects:: + Do not use replacement refs to replace Git objects. + This is equivalent to exporting the `GIT_NO_REPLACE_OBJECTS` + environment variable with any value. + See linkgit:git-replace[1] for more information. + +--no-lazy-fetch:: + Do not fetch missing objects from the promisor remote on + demand. Useful together with `git cat-file -e ` to + see if the object is locally available. + This is equivalent to setting the `GIT_NO_LAZY_FETCH` + environment variable to `1`. + +--no-optional-locks:: + Do not perform optional operations that require locks. This is + equivalent to setting the `GIT_OPTIONAL_LOCKS` to `0`. + +--no-advice:: + Disable all advice hints from being printed. + +--literal-pathspecs:: + Treat pathspecs literally (i.e. no globbing, no pathspec magic). + This is equivalent to setting the `GIT_LITERAL_PATHSPECS` environment + variable to `1`. + +--glob-pathspecs:: + Add "glob" magic to all pathspec. This is equivalent to setting + the `GIT_GLOB_PATHSPECS` environment variable to `1`. Disabling + globbing on individual pathspecs can be done using pathspec + magic ":(literal)" + +--noglob-pathspecs:: + Add "literal" magic to all pathspec. This is equivalent to setting + the `GIT_NOGLOB_PATHSPECS` environment variable to `1`. Enabling + globbing on individual pathspecs can be done using pathspec + magic ":(glob)" + +--icase-pathspecs:: + Add "icase" magic to all pathspec. This is equivalent to setting + the `GIT_ICASE_PATHSPECS` environment variable to `1`. + +--list-cmds=[,...]:: + List commands by group. This is an internal/experimental + option and may change or be removed in the future. Supported + groups are: builtins, parseopt (builtin commands that use + parse-options), main (all commands in libexec directory), + others (all other commands in `$PATH` that have git- prefix), + list- (see categories in command-list.txt), + nohelpers (exclude helper commands), alias and config + (retrieve command list from config variable completion.commands) + +--attr-source=:: + Read gitattributes from instead of the worktree. See + linkgit:gitattributes[5]. This is equivalent to setting the + `GIT_ATTR_SOURCE` environment variable. + +GIT COMMANDS +------------ + +We divide Git into high level ("porcelain") commands and low level +("plumbing") commands. + +High-level commands (porcelain) +------------------------------- + +We separate the porcelain commands into the main commands and some +ancillary user utilities. + +Main porcelain commands +~~~~~~~~~~~~~~~~~~~~~~~ + +linkgit:git-add[1]:: + Add file contents to the index + +linkgit:git-am[1]:: + Apply a series of patches from a mailbox + +linkgit:git-archive[1]:: + Create an archive of files from a named tree + +linkgit:git-bisect[1]:: + Use binary search to find the commit that introduced a bug + +linkgit:git-branch[1]:: + List, create, or delete branches + +linkgit:git-bundle[1]:: + Move objects and refs by archive + +linkgit:git-checkout[1]:: + Switch branches or restore working tree files + +linkgit:git-cherry-pick[1]:: + Apply the changes introduced by some existing commits + +linkgit:git-citool[1]:: + Graphical alternative to git-commit + +linkgit:git-clean[1]:: + Remove untracked files from the working tree + +linkgit:git-clone[1]:: + Clone a repository into a new directory + +linkgit:git-commit[1]:: + Record changes to the repository + +linkgit:git-describe[1]:: + Give an object a human readable name based on an available ref + +linkgit:git-diff[1]:: + Show changes between commits, commit and working tree, etc + +linkgit:git-fetch[1]:: + Download objects and refs from another repository + +linkgit:git-format-patch[1]:: + Prepare patches for e-mail submission + +linkgit:git-gc[1]:: + Cleanup unnecessary files and optimize the local repository + +linkgit:git-grep[1]:: + Print lines matching a pattern + +linkgit:git-gui[1]:: + A portable graphical interface to Git + +linkgit:git-init[1]:: + Create an empty Git repository or reinitialize an existing one + +linkgit:git-log[1]:: + Show commit logs + +linkgit:git-maintenance[1]:: + Run tasks to optimize Git repository data + +linkgit:git-merge[1]:: + Join two or more development histories together + +linkgit:git-mv[1]:: + Move or rename a file, a directory, or a symlink + +linkgit:git-notes[1]:: + Add or inspect object notes + +linkgit:git-pull[1]:: + Fetch from and integrate with another repository or a local branch + +linkgit:git-push[1]:: + Update remote refs along with associated objects + +linkgit:git-range-diff[1]:: + Compare two commit ranges (e.g. two versions of a branch) + +linkgit:git-rebase[1]:: + Reapply commits on top of another base tip + +linkgit:git-reset[1]:: + Reset current HEAD to the specified state + +linkgit:git-restore[1]:: + Restore working tree files + +linkgit:git-revert[1]:: + Revert some existing commits + +linkgit:git-rm[1]:: + Remove files from the working tree and from the index + +linkgit:git-shortlog[1]:: + Summarize 'git log' output + +linkgit:git-show[1]:: + Show various types of objects + +linkgit:git-sparse-checkout[1]:: + Reduce your working tree to a subset of tracked files + +linkgit:git-stash[1]:: + Stash the changes in a dirty working directory away + +linkgit:git-status[1]:: + Show the working tree status + +linkgit:git-submodule[1]:: + Initialize, update or inspect submodules + +linkgit:git-switch[1]:: + Switch branches + +linkgit:git-tag[1]:: + Create, list, delete or verify a tag object signed with GPG + +linkgit:git-worktree[1]:: + Manage multiple working trees + +linkgit:gitk[1]:: + The Git repository browser + +linkgit:scalar[1]:: + A tool for managing large Git repositories + + +Ancillary Commands +~~~~~~~~~~~~~~~~~~ +Manipulators: + +linkgit:git-config[1]:: + Get and set repository or global options + +linkgit:git-fast-export[1]:: + Git data exporter + +linkgit:git-fast-import[1]:: + Backend for fast Git data importers + +linkgit:git-filter-branch[1]:: + Rewrite branches + +linkgit:git-mergetool[1]:: + Run merge conflict resolution tools to resolve merge conflicts + +linkgit:git-pack-refs[1]:: + Pack heads and tags for efficient repository access + +linkgit:git-prune[1]:: + Prune all unreachable objects from the object database + +linkgit:git-reflog[1]:: + Manage reflog information + +linkgit:git-refs[1]:: + Low-level access to refs + +linkgit:git-remote[1]:: + Manage set of tracked repositories + +linkgit:git-repack[1]:: + Pack unpacked objects in a repository + +linkgit:git-replace[1]:: + Create, list, delete refs to replace objects + + +Interrogators: + +linkgit:git-annotate[1]:: + Annotate file lines with commit information + +linkgit:git-blame[1]:: + Show what revision and author last modified each line of a file + +linkgit:git-bugreport[1]:: + Collect information for user to file a bug report + +linkgit:git-count-objects[1]:: + Count unpacked number of objects and their disk consumption + +linkgit:git-diagnose[1]:: + Generate a zip archive of diagnostic information + +linkgit:git-difftool[1]:: + Show changes using common diff tools + +linkgit:git-fsck[1]:: + Verifies the connectivity and validity of the objects in the database + +linkgit:git-help[1]:: + Display help information about Git + +linkgit:git-instaweb[1]:: + Instantly browse your working repository in gitweb + +linkgit:git-merge-tree[1]:: + Perform merge without touching index or working tree + +linkgit:git-rerere[1]:: + Reuse recorded resolution of conflicted merges + +linkgit:git-show-branch[1]:: + Show branches and their commits + +linkgit:git-verify-commit[1]:: + Check the GPG signature of commits + +linkgit:git-verify-tag[1]:: + Check the GPG signature of tags + +linkgit:git-version[1]:: + Display version information about Git + +linkgit:git-whatchanged[1]:: + Show logs with differences each commit introduces + +linkgit:gitweb[1]:: + Git web interface (web frontend to Git repositories) + + + +Interacting with Others +~~~~~~~~~~~~~~~~~~~~~~~ + +These commands are to interact with foreign SCM and with other +people via patch over e-mail. + +linkgit:git-archimport[1]:: + Import a GNU Arch repository into Git + +linkgit:git-cvsexportcommit[1]:: + Export a single commit to a CVS checkout + +linkgit:git-cvsimport[1]:: + Salvage your data out of another SCM people love to hate + +linkgit:git-cvsserver[1]:: + A CVS server emulator for Git + +linkgit:git-imap-send[1]:: + Send a collection of patches from stdin to an IMAP folder + +linkgit:git-p4[1]:: + Import from and submit to Perforce repositories + +linkgit:git-quiltimport[1]:: + Applies a quilt patchset onto the current branch + +linkgit:git-request-pull[1]:: + Generates a summary of pending changes + +linkgit:git-send-email[1]:: + Send a collection of patches as emails + +linkgit:git-svn[1]:: + Bidirectional operation between a Subversion repository and Git + + +Reset, restore and revert +~~~~~~~~~~~~~~~~~~~~~~~~~ +There are three commands with similar names: `git reset`, +`git restore` and `git revert`. + +* linkgit:git-revert[1] is about making a new commit that reverts the + changes made by other commits. + +* linkgit:git-restore[1] is about restoring files in the working tree + from either the index or another commit. This command does not + update your branch. The command can also be used to restore files in + the index from another commit. + +* linkgit:git-reset[1] is about updating your branch, moving the tip + in order to add or remove commits from the branch. This operation + changes the commit history. ++ +`git reset` can also be used to restore the index, overlapping with +`git restore`. + + +Low-level commands (plumbing) +----------------------------- + +Although Git includes its +own porcelain layer, its low-level commands are sufficient to support +development of alternative porcelains. Developers of such porcelains +might start by reading about linkgit:git-update-index[1] and +linkgit:git-read-tree[1]. + +The interface (input, output, set of options and the semantics) +to these low-level commands are meant to be a lot more stable +than Porcelain level commands, because these commands are +primarily for scripted use. The interface to Porcelain commands +on the other hand are subject to change in order to improve the +end user experience. + +The following description divides +the low-level commands into commands that manipulate objects (in +the repository, index, and working tree), commands that interrogate and +compare objects, and commands that move objects and references between +repositories. + + +Manipulation commands +~~~~~~~~~~~~~~~~~~~~~ + +linkgit:git-apply[1]:: + Apply a patch to files and/or to the index + +linkgit:git-checkout-index[1]:: + Copy files from the index to the working tree + +linkgit:git-commit-graph[1]:: + Write and verify Git commit-graph files + +linkgit:git-commit-tree[1]:: + Create a new commit object + +linkgit:git-hash-object[1]:: + Compute object ID and optionally create an object from a file + +linkgit:git-index-pack[1]:: + Build pack index file for an existing packed archive + +linkgit:git-merge-file[1]:: + Run a three-way file merge + +linkgit:git-merge-index[1]:: + Run a merge for files needing merging + +linkgit:git-mktag[1]:: + Creates a tag object with extra validation + +linkgit:git-mktree[1]:: + Build a tree-object from ls-tree formatted text + +linkgit:git-multi-pack-index[1]:: + Write and verify multi-pack-indexes + +linkgit:git-pack-objects[1]:: + Create a packed archive of objects + +linkgit:git-prune-packed[1]:: + Remove extra objects that are already in pack files + +linkgit:git-read-tree[1]:: + Reads tree information into the index + +linkgit:git-replay[1]:: + EXPERIMENTAL: Replay commits on a new base, works with bare repos too + +linkgit:git-symbolic-ref[1]:: + Read, modify and delete symbolic refs + +linkgit:git-unpack-objects[1]:: + Unpack objects from a packed archive + +linkgit:git-update-index[1]:: + Register file contents in the working tree to the index + +linkgit:git-update-ref[1]:: + Update the object name stored in a ref safely + +linkgit:git-write-tree[1]:: + Create a tree object from the current index + + + +Interrogation commands +~~~~~~~~~~~~~~~~~~~~~~ + +linkgit:git-cat-file[1]:: + Provide contents or details of repository objects + +linkgit:git-cherry[1]:: + Find commits yet to be applied to upstream + +linkgit:git-diff-files[1]:: + Compares files in the working tree and the index + +linkgit:git-diff-index[1]:: + Compare a tree to the working tree or index + +linkgit:git-diff-tree[1]:: + Compares the content and mode of blobs found via two tree objects + +linkgit:git-for-each-ref[1]:: + Output information on each ref + +linkgit:git-for-each-repo[1]:: + Run a Git command on a list of repositories + +linkgit:git-get-tar-commit-id[1]:: + Extract commit ID from an archive created using git-archive + +linkgit:git-ls-files[1]:: + Show information about files in the index and the working tree + +linkgit:git-ls-remote[1]:: + List references in a remote repository + +linkgit:git-ls-tree[1]:: + List the contents of a tree object + +linkgit:git-merge-base[1]:: + Find as good common ancestors as possible for a merge + +linkgit:git-name-rev[1]:: + Find symbolic names for given revs + +linkgit:git-pack-redundant[1]:: + Find redundant pack files + +linkgit:git-rev-list[1]:: + Lists commit objects in reverse chronological order + +linkgit:git-rev-parse[1]:: + Pick out and massage parameters + +linkgit:git-show-index[1]:: + Show packed archive index + +linkgit:git-show-ref[1]:: + List references in a local repository + +linkgit:git-unpack-file[1]:: + Creates a temporary file with a blob's contents + +linkgit:git-var[1]:: + Show a Git logical variable + +linkgit:git-verify-pack[1]:: + Validate packed Git archive files + + +In general, the interrogate commands do not touch the files in +the working tree. + + +Syncing repositories +~~~~~~~~~~~~~~~~~~~~ + +linkgit:git-daemon[1]:: + A really simple server for Git repositories + +linkgit:git-fetch-pack[1]:: + Receive missing objects from another repository + +linkgit:git-http-backend[1]:: + Server side implementation of Git over HTTP + +linkgit:git-send-pack[1]:: + Push objects over Git protocol to another repository + +linkgit:git-update-server-info[1]:: + Update auxiliary info file to help dumb servers + + +The following are helper commands used by the above; end users +typically do not use them directly. + +linkgit:git-http-fetch[1]:: + Download from a remote Git repository via HTTP + +linkgit:git-http-push[1]:: + Push objects over HTTP/DAV to another repository + +linkgit:git-receive-pack[1]:: + Receive what is pushed into the repository + +linkgit:git-shell[1]:: + Restricted login shell for Git-only SSH access + +linkgit:git-upload-archive[1]:: + Send archive back to git-archive + +linkgit:git-upload-pack[1]:: + Send objects packed back to git-fetch-pack + + + +Internal helper commands +~~~~~~~~~~~~~~~~~~~~~~~~ + +These are internal helper commands used by other commands; end +users typically do not use them directly. + +linkgit:git-check-attr[1]:: + Display gitattributes information + +linkgit:git-check-ignore[1]:: + Debug gitignore / exclude files + +linkgit:git-check-mailmap[1]:: + Show canonical names and email addresses of contacts + +linkgit:git-check-ref-format[1]:: + Ensures that a reference name is well formed + +linkgit:git-column[1]:: + Display data in columns + +linkgit:git-credential[1]:: + Retrieve and store user credentials + +linkgit:git-credential-cache[1]:: + Helper to temporarily store passwords in memory + +linkgit:git-credential-store[1]:: + Helper to store credentials on disk + +linkgit:git-fmt-merge-msg[1]:: + Produce a merge commit message + +linkgit:git-hook[1]:: + Run git hooks + +linkgit:git-interpret-trailers[1]:: + Add or parse structured information in commit messages + +linkgit:git-mailinfo[1]:: + Extracts patch and authorship from a single e-mail message + +linkgit:git-mailsplit[1]:: + Simple UNIX mbox splitter program + +linkgit:git-merge-one-file[1]:: + The standard helper program to use with git-merge-index + +linkgit:git-patch-id[1]:: + Compute unique ID for a patch + +linkgit:git-sh-i18n[1]:: + Git's i18n setup code for shell scripts + +linkgit:git-sh-setup[1]:: + Common Git shell script setup code + +linkgit:git-stripspace[1]:: + Remove unnecessary whitespace + + +Guides +------ + +The following documentation pages are guides about Git concepts. + +linkgit:gitcore-tutorial[7]:: + A Git core tutorial for developers + +linkgit:gitcredentials[7]:: + Providing usernames and passwords to Git + +linkgit:gitcvs-migration[7]:: + Git for CVS users + +linkgit:gitdiffcore[7]:: + Tweaking diff output + +linkgit:giteveryday[7]:: + A useful minimum set of commands for Everyday Git + +linkgit:gitfaq[7]:: + Frequently asked questions about using Git + +linkgit:gitglossary[7]:: + A Git Glossary + +linkgit:gitnamespaces[7]:: + Git namespaces + +linkgit:gitremote-helpers[7]:: + Helper programs to interact with remote repositories + +linkgit:gitsubmodules[7]:: + Mounting one repository inside another + +linkgit:gittutorial[7]:: + A tutorial introduction to Git + +linkgit:gittutorial-2[7]:: + A tutorial introduction to Git: part two + +linkgit:gitworkflows[7]:: + An overview of recommended workflows with Git + + +Repository, command and file interfaces +--------------------------------------- + +This documentation discusses repository and command interfaces which +users are expected to interact with directly. See `--user-formats` in +linkgit:git-help[1] for more details on the criteria. + +linkgit:gitattributes[5]:: + Defining attributes per path + +linkgit:gitcli[7]:: + Git command-line interface and conventions + +linkgit:githooks[5]:: + Hooks used by Git + +linkgit:gitignore[5]:: + Specifies intentionally untracked files to ignore + +linkgit:gitmailmap[5]:: + Map author/committer names and/or E-Mail addresses + +linkgit:gitmodules[5]:: + Defining submodule properties + +linkgit:gitrepository-layout[5]:: + Git Repository Layout + +linkgit:gitrevisions[7]:: + Specifying revisions and ranges for Git + + +File formats, protocols and other developer interfaces +------------------------------------------------------ + +This documentation discusses file formats, over-the-wire protocols and +other git developer interfaces. See `--developer-interfaces` in +linkgit:git-help[1]. + +linkgit:gitformat-bundle[5]:: + The bundle file format + +linkgit:gitformat-chunk[5]:: + Chunk-based file formats + +linkgit:gitformat-commit-graph[5]:: + Git commit-graph format + +linkgit:gitformat-index[5]:: + Git index format + +linkgit:gitformat-pack[5]:: + Git pack format + +linkgit:gitformat-signature[5]:: + Git cryptographic signature formats + +linkgit:gitprotocol-capabilities[5]:: + Protocol v0 and v1 capabilities + +linkgit:gitprotocol-common[5]:: + Things common to various protocols + +linkgit:gitprotocol-http[5]:: + Git HTTP-based protocols + +linkgit:gitprotocol-pack[5]:: + How packs are transferred over-the-wire + +linkgit:gitprotocol-v2[5]:: + Git Wire Protocol, Version 2 + + +Configuration Mechanism +----------------------- + +Git uses a simple text format to store customizations that are per +repository and are per user. Such a configuration file may look +like this: + +------------ +# +# A '#' or ';' character indicates a comment. +# + +; core variables +[core] + ; Don't trust file modes + filemode = false + +; user identity +[user] + name = "Junio C Hamano" + email = "gitster@pobox.com" + +------------ + +Various commands read from the configuration file and adjust +their operation accordingly. See linkgit:git-config[1] for a +list and more details about the configuration mechanism. + + +Identifier Terminology +---------------------- +:: + Indicates the object name for any type of object. + +:: + Indicates a blob object name. + +:: + Indicates a tree object name. + +:: + Indicates a commit object name. + +:: + Indicates a tree, commit or tag object name. A + command that takes a argument ultimately wants to + operate on a object but automatically dereferences + and objects that point at a . + +:: + Indicates a commit or tag object name. A + command that takes a argument ultimately wants to + operate on a object but automatically dereferences + objects that point at a . + +:: + Indicates that an object type is required. + Currently one of: `blob`, `tree`, `commit`, or `tag`. + +:: + Indicates a filename - almost always relative to the + root of the tree structure `GIT_INDEX_FILE` describes. + +Symbolic Identifiers +-------------------- +Any Git command accepting any can also use the following +symbolic notation: + +HEAD:: + indicates the head of the current branch. + +:: + a valid tag 'name' + (i.e. a `refs/tags/` reference). + +:: + a valid head 'name' + (i.e. a `refs/heads/` reference). + +For a more complete list of ways to spell object names, see +"SPECIFYING REVISIONS" section in linkgit:gitrevisions[7]. + + +File/Directory Structure +------------------------ + +Please see the linkgit:gitrepository-layout[5] document. + +Read linkgit:githooks[5] for more details about each hook. + +Higher level SCMs may provide and manage additional information in the +`$GIT_DIR`. + + +Terminology +----------- +Please see linkgit:gitglossary[7]. + + +Environment Variables +--------------------- +Various Git commands pay attention to environment variables and change +their behavior. The environment variables marked as "Boolean" take +their values the same way as Boolean valued configuration variables, e.g. +"true", "yes", "on" and positive numbers are taken as "yes". + +Here are the variables: + +System +~~~~~~ +`HOME`:: + Specifies the path to the user's home directory. On Windows, if + unset, Git will set a process environment variable equal to: + `$HOMEDRIVE$HOMEPATH` if both `$HOMEDRIVE` and `$HOMEPATH` exist; + otherwise `$USERPROFILE` if `$USERPROFILE` exists. + +The Git Repository +~~~~~~~~~~~~~~~~~~ +These environment variables apply to 'all' core Git commands. Nb: it +is worth noting that they may be used/overridden by SCMS sitting above +Git so take care if using a foreign front-end. + +`GIT_INDEX_FILE`:: + This environment variable specifies an alternate + index file. If not specified, the default of `$GIT_DIR/index` + is used. + +`GIT_INDEX_VERSION`:: + This environment variable specifies what index version is used + when writing the index file out. It won't affect existing index + files. By default index file version 2 or 3 is used. See + linkgit:git-update-index[1] for more information. + +`GIT_OBJECT_DIRECTORY`:: + If the object storage directory is specified via this + environment variable then the sha1 directories are created + underneath - otherwise the default `$GIT_DIR/objects` + directory is used. + +`GIT_ALTERNATE_OBJECT_DIRECTORIES`:: + Due to the immutable nature of Git objects, old objects can be + archived into shared, read-only directories. This variable + specifies a ":" separated (on Windows ";" separated) list + of Git object directories which can be used to search for Git + objects. New objects will not be written to these directories. ++ +Entries that begin with `"` (double-quote) will be interpreted +as C-style quoted paths, removing leading and trailing +double-quotes and respecting backslash escapes. E.g., the value +`"path-with-\"-and-:-in-it":vanilla-path` has two paths: +`path-with-"-and-:-in-it` and `vanilla-path`. + +`GIT_DIR`:: + If the `GIT_DIR` environment variable is set then it + specifies a path to use instead of the default `.git` + for the base of the repository. + The `--git-dir` command-line option also sets this value. + +`GIT_WORK_TREE`:: + Set the path to the root of the working tree. + This can also be controlled by the `--work-tree` command-line + option and the core.worktree configuration variable. + +`GIT_NAMESPACE`:: + Set the Git namespace; see linkgit:gitnamespaces[7] for details. + The `--namespace` command-line option also sets this value. + +`GIT_CEILING_DIRECTORIES`:: + This should be a colon-separated list of absolute paths. If + set, it is a list of directories that Git should not chdir up + into while looking for a repository directory (useful for + excluding slow-loading network directories). It will not + exclude the current working directory or a GIT_DIR set on the + command line or in the environment. Normally, Git has to read + the entries in this list and resolve any symlink that + might be present in order to compare them with the current + directory. However, if even this access is slow, you + can add an empty entry to the list to tell Git that the + subsequent entries are not symlinks and needn't be resolved; + e.g., + `GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink`. + +`GIT_DISCOVERY_ACROSS_FILESYSTEM`:: + When run in a directory that does not have ".git" repository + directory, Git tries to find such a directory in the parent + directories to find the top of the working tree, but by default it + does not cross filesystem boundaries. This Boolean environment variable + can be set to true to tell Git not to stop at filesystem + boundaries. Like `GIT_CEILING_DIRECTORIES`, this will not affect + an explicit repository directory set via `GIT_DIR` or on the + command line. + +`GIT_COMMON_DIR`:: + If this variable is set to a path, non-worktree files that are + normally in $GIT_DIR will be taken from this path + instead. Worktree-specific files such as HEAD or index are + taken from $GIT_DIR. See linkgit:gitrepository-layout[5] and + linkgit:git-worktree[1] for + details. This variable has lower precedence than other path + variables such as GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY... + +`GIT_DEFAULT_HASH`:: + If this variable is set, the default hash algorithm for new + repositories will be set to this value. This value is + ignored when cloning and the setting of the remote repository + is always used. The default is "sha1". + See `--object-format` in linkgit:git-init[1]. + +`GIT_DEFAULT_REF_FORMAT`:: + If this variable is set, the default reference backend format for new + repositories will be set to this value. The default is "files". + See `--ref-format` in linkgit:git-init[1]. + +Git Commits +~~~~~~~~~~~ +`GIT_AUTHOR_NAME`:: + The human-readable name used in the author identity when creating commit or + tag objects, or when writing reflogs. Overrides the `user.name` and + `author.name` configuration settings. + +`GIT_AUTHOR_EMAIL`:: + The email address used in the author identity when creating commit or + tag objects, or when writing reflogs. Overrides the `user.email` and + `author.email` configuration settings. + +`GIT_AUTHOR_DATE`:: + The date used for the author identity when creating commit or tag objects, or + when writing reflogs. See linkgit:git-commit[1] for valid formats. + +`GIT_COMMITTER_NAME`:: + The human-readable name used in the committer identity when creating commit or + tag objects, or when writing reflogs. Overrides the `user.name` and + `committer.name` configuration settings. + +`GIT_COMMITTER_EMAIL`:: + The email address used in the author identity when creating commit or + tag objects, or when writing reflogs. Overrides the `user.email` and + `committer.email` configuration settings. + +`GIT_COMMITTER_DATE`:: + The date used for the committer identity when creating commit or tag objects, or + when writing reflogs. See linkgit:git-commit[1] for valid formats. + +`EMAIL`:: + The email address used in the author and committer identities if no other + relevant environment variable or configuration setting has been set. + +Git Diffs +~~~~~~~~~ +`GIT_DIFF_OPTS`:: + Only valid setting is "--unified=??" or "-u??" to set the + number of context lines shown when a unified diff is created. + This takes precedence over any "-U" or "--unified" option + value passed on the Git diff command line. + +`GIT_EXTERNAL_DIFF`:: + When the environment variable `GIT_EXTERNAL_DIFF` is set, the + program named by it is called to generate diffs, and Git + does not use its builtin diff machinery. + For a path that is added, removed, or modified, + `GIT_EXTERNAL_DIFF` is called with 7 parameters: + + path old-file old-hex old-mode new-file new-hex new-mode ++ +where: + + -file:: are files GIT_EXTERNAL_DIFF can use to read the + contents of , + -hex:: are the 40-hexdigit SHA-1 hashes, + -mode:: are the octal representation of the file modes. ++ +The file parameters can point at the user's working file +(e.g. `new-file` in "git-diff-files"), `/dev/null` (e.g. `old-file` +when a new file is added), or a temporary file (e.g. `old-file` in the +index). `GIT_EXTERNAL_DIFF` should not worry about unlinking the +temporary file -- it is removed when `GIT_EXTERNAL_DIFF` exits. ++ +For a path that is unmerged, `GIT_EXTERNAL_DIFF` is called with 1 +parameter, . ++ +For each path `GIT_EXTERNAL_DIFF` is called, two environment variables, +`GIT_DIFF_PATH_COUNTER` and `GIT_DIFF_PATH_TOTAL` are set. + +`GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE`:: + If this Boolean environment variable is set to true then the + `GIT_EXTERNAL_DIFF` command is expected to return exit code + 0 if it considers the input files to be equal or 1 if it + considers them to be different, like `diff(1)`. + If it is set to false, which is the default, then the command + is expected to return exit code 0 regardless of equality. + Any other exit code causes Git to report a fatal error. + + +`GIT_DIFF_PATH_COUNTER`:: + A 1-based counter incremented by one for every path. + +`GIT_DIFF_PATH_TOTAL`:: + The total number of paths. + +other +~~~~~ +`GIT_MERGE_VERBOSITY`:: + A number controlling the amount of output shown by + the recursive merge strategy. Overrides merge.verbosity. + See linkgit:git-merge[1] + +`GIT_PAGER`:: + This environment variable overrides `$PAGER`. If it is set + to an empty string or to the value "cat", Git will not launch + a pager. See also the `core.pager` option in + linkgit:git-config[1]. + +`GIT_PROGRESS_DELAY`:: + A number controlling how many seconds to delay before showing + optional progress indicators. Defaults to 2. + +`GIT_EDITOR`:: + This environment variable overrides `$EDITOR` and `$VISUAL`. + It is used by several Git commands when, on interactive mode, + an editor is to be launched. See also linkgit:git-var[1] + and the `core.editor` option in linkgit:git-config[1]. + +`GIT_SEQUENCE_EDITOR`:: + This environment variable overrides the configured Git editor + when editing the todo list of an interactive rebase. See also + linkgit:git-rebase[1] and the `sequence.editor` option in + linkgit:git-config[1]. + +`GIT_SSH`:: +`GIT_SSH_COMMAND`:: + If either of these environment variables is set then 'git fetch' + and 'git push' will use the specified command instead of 'ssh' + when they need to connect to a remote system. + The command-line parameters passed to the configured command are + determined by the ssh variant. See `ssh.variant` option in + linkgit:git-config[1] for details. ++ +`$GIT_SSH_COMMAND` takes precedence over `$GIT_SSH`, and is interpreted +by the shell, which allows additional arguments to be included. +`$GIT_SSH` on the other hand must be just the path to a program +(which can be a wrapper shell script, if additional arguments are +needed). ++ +Usually it is easier to configure any desired options through your +personal `.ssh/config` file. Please consult your ssh documentation +for further details. + +`GIT_SSH_VARIANT`:: + If this environment variable is set, it overrides Git's autodetection + whether `GIT_SSH`/`GIT_SSH_COMMAND`/`core.sshCommand` refer to OpenSSH, + plink or tortoiseplink. This variable overrides the config setting + `ssh.variant` that serves the same purpose. + +`GIT_SSL_NO_VERIFY`:: + Setting and exporting this environment variable to any value + tells Git not to verify the SSL certificate when fetching or + pushing over HTTPS. + +`GIT_ATTR_SOURCE`:: + Sets the treeish that gitattributes will be read from. + +`GIT_ASKPASS`:: + If this environment variable is set, then Git commands which need to + acquire passwords or passphrases (e.g. for HTTP or IMAP authentication) + will call this program with a suitable prompt as command-line argument + and read the password from its STDOUT. See also the `core.askPass` + option in linkgit:git-config[1]. + +`GIT_TERMINAL_PROMPT`:: + If this Boolean environment variable is set to false, git will not prompt + on the terminal (e.g., when asking for HTTP authentication). + +`GIT_CONFIG_GLOBAL`:: +`GIT_CONFIG_SYSTEM`:: + Take the configuration from the given files instead from global or + system-level configuration files. If `GIT_CONFIG_SYSTEM` is set, the + system config file defined at build time (usually `/etc/gitconfig`) + will not be read. Likewise, if `GIT_CONFIG_GLOBAL` is set, neither + `$HOME/.gitconfig` nor `$XDG_CONFIG_HOME/git/config` will be read. Can + be set to `/dev/null` to skip reading configuration files of the + respective level. + +`GIT_CONFIG_NOSYSTEM`:: + Whether to skip reading settings from the system-wide + `$(prefix)/etc/gitconfig` file. This Boolean environment variable can + be used along with `$HOME` and `$XDG_CONFIG_HOME` to create a + predictable environment for a picky script, or you can set it + to true to temporarily avoid using a buggy `/etc/gitconfig` file while + waiting for someone with sufficient permissions to fix it. + +`GIT_FLUSH`:: + If this Boolean environment variable is set to true, then commands such + as 'git blame' (in incremental mode), 'git rev-list', 'git log', + 'git check-attr' and 'git check-ignore' will + force a flush of the output stream after each record have been + flushed. If this + variable is set to false, the output of these commands will be done + using completely buffered I/O. If this environment variable is + not set, Git will choose buffered or record-oriented flushing + based on whether stdout appears to be redirected to a file or not. + +`GIT_TRACE`:: + Enables general trace messages, e.g. alias expansion, built-in + command execution and external command execution. ++ +If this variable is set to "1", "2" or "true" (comparison +is case insensitive), trace messages will be printed to +stderr. ++ +If the variable is set to an integer value greater than 2 +and lower than 10 (strictly) then Git will interpret this +value as an open file descriptor and will try to write the +trace messages into this file descriptor. ++ +Alternatively, if the variable is set to an absolute path +(starting with a '/' character), Git will interpret this +as a file path and will try to append the trace messages +to it. ++ +Unsetting the variable, or setting it to empty, "0" or +"false" (case insensitive) disables trace messages. + +`GIT_TRACE_FSMONITOR`:: + Enables trace messages for the filesystem monitor extension. + See `GIT_TRACE` for available trace output options. + +`GIT_TRACE_PACK_ACCESS`:: + Enables trace messages for all accesses to any packs. For each + access, the pack file name and an offset in the pack is + recorded. This may be helpful for troubleshooting some + pack-related performance problems. + See `GIT_TRACE` for available trace output options. + +`GIT_TRACE_PACKET`:: + Enables trace messages for all packets coming in or out of a + given program. This can help with debugging object negotiation + or other protocol issues. Tracing is turned off at a packet + starting with "PACK" (but see `GIT_TRACE_PACKFILE` below). + See `GIT_TRACE` for available trace output options. + +`GIT_TRACE_PACKFILE`:: + Enables tracing of packfiles sent or received by a + given program. Unlike other trace output, this trace is + verbatim: no headers, and no quoting of binary data. You almost + certainly want to direct into a file (e.g., + `GIT_TRACE_PACKFILE=/tmp/my.pack`) rather than displaying it on + the terminal or mixing it with other trace output. ++ +Note that this is currently only implemented for the client side +of clones and fetches. + +`GIT_TRACE_PERFORMANCE`:: + Enables performance related trace messages, e.g. total execution + time of each Git command. + See `GIT_TRACE` for available trace output options. + +`GIT_TRACE_REFS`:: + Enables trace messages for operations on the ref database. + See `GIT_TRACE` for available trace output options. + +`GIT_TRACE_SETUP`:: + Enables trace messages printing the .git, working tree and current + working directory after Git has completed its setup phase. + See `GIT_TRACE` for available trace output options. + +`GIT_TRACE_SHALLOW`:: + Enables trace messages that can help debugging fetching / + cloning of shallow repositories. + See `GIT_TRACE` for available trace output options. + +`GIT_TRACE_CURL`:: + Enables a curl full trace dump of all incoming and outgoing data, + including descriptive information, of the git transport protocol. + This is similar to doing curl `--trace-ascii` on the command line. + See `GIT_TRACE` for available trace output options. + +`GIT_TRACE_CURL_NO_DATA`:: + When a curl trace is enabled (see `GIT_TRACE_CURL` above), do not dump + data (that is, only dump info lines and headers). + +`GIT_TRACE2`:: + Enables more detailed trace messages from the "trace2" library. + Output from `GIT_TRACE2` is a simple text-based format for human + readability. ++ +If this variable is set to "1", "2" or "true" (comparison +is case insensitive), trace messages will be printed to +stderr. ++ +If the variable is set to an integer value greater than 2 +and lower than 10 (strictly) then Git will interpret this +value as an open file descriptor and will try to write the +trace messages into this file descriptor. ++ +Alternatively, if the variable is set to an absolute path +(starting with a '/' character), Git will interpret this +as a file path and will try to append the trace messages +to it. If the path already exists and is a directory, the +trace messages will be written to files (one per process) +in that directory, named according to the last component +of the SID and an optional counter (to avoid filename +collisions). ++ +In addition, if the variable is set to +`af_unix:[:]`, Git will try +to open the path as a Unix Domain Socket. The socket type +can be either `stream` or `dgram`. ++ +Unsetting the variable, or setting it to empty, "0" or +"false" (case insensitive) disables trace messages. ++ +See link:/docs/api-trace2[Trace2 documentation] +for full details. + + +`GIT_TRACE2_EVENT`:: + This setting writes a JSON-based format that is suited for machine + interpretation. + See `GIT_TRACE2` for available trace output options and + link:/docs/api-trace2[Trace2 documentation] for full details. + +`GIT_TRACE2_PERF`:: + In addition to the text-based messages available in `GIT_TRACE2`, this + setting writes a column-based format for understanding nesting + regions. + See `GIT_TRACE2` for available trace output options and + link:/docs/api-trace2[Trace2 documentation] for full details. + +`GIT_TRACE_REDACT`:: + By default, when tracing is activated, Git redacts the values of + cookies, the "Authorization:" header, the "Proxy-Authorization:" + header and packfile URIs. Set this Boolean environment variable to false to prevent this + redaction. + +`GIT_NO_REPLACE_OBJECTS`:: + Setting and exporting this environment variable tells Git to + ignore replacement refs and do not replace Git objects. + +`GIT_LITERAL_PATHSPECS`:: + Setting this Boolean environment variable to true will cause Git to treat all + pathspecs literally, rather than as glob patterns. For example, + running `GIT_LITERAL_PATHSPECS=1 git log -- '*.c'` will search + for commits that touch the path `*.c`, not any paths that the + glob `*.c` matches. You might want this if you are feeding + literal paths to Git (e.g., paths previously given to you by + `git ls-tree`, `--raw` diff output, etc). + +`GIT_GLOB_PATHSPECS`:: + Setting this Boolean environment variable to true will cause Git to treat all + pathspecs as glob patterns (aka "glob" magic). + +`GIT_NOGLOB_PATHSPECS`:: + Setting this Boolean environment variable to true will cause Git to treat all + pathspecs as literal (aka "literal" magic). + +`GIT_ICASE_PATHSPECS`:: + Setting this Boolean environment variable to true will cause Git to treat all + pathspecs as case-insensitive. + +`GIT_NO_LAZY_FETCH`:: + Setting this Boolean environment variable to true tells Git + not to lazily fetch missing objects from the promisor remote + on demand. + +`GIT_REFLOG_ACTION`:: + When a ref is updated, reflog entries are created to keep + track of the reason why the ref was updated (which is + typically the name of the high-level command that updated + the ref), in addition to the old and new values of the ref. + A scripted Porcelain command can use set_reflog_action + helper function in `git-sh-setup` to set its name to this + variable when it is invoked as the top level command by the + end user, to be recorded in the body of the reflog. + +`GIT_REF_PARANOIA`:: + If this Boolean environment variable is set to false, ignore broken or badly named refs when iterating + over lists of refs. Normally Git will try to include any such + refs, which may cause some operations to fail. This is usually + preferable, as potentially destructive operations (e.g., + linkgit:git-prune[1]) are better off aborting rather than + ignoring broken refs (and thus considering the history they + point to as not worth saving). The default value is `1` (i.e., + be paranoid about detecting and aborting all operations). You + should not normally need to set this to `0`, but it may be + useful when trying to salvage data from a corrupted repository. + +`GIT_COMMIT_GRAPH_PARANOIA`:: + When loading a commit object from the commit-graph, Git performs an + existence check on the object in the object database. This is done to + avoid issues with stale commit-graphs that contain references to + already-deleted commits, but comes with a performance penalty. ++ +The default is "false", which disables the aforementioned behavior. +Setting this to "true" enables the existence check so that stale commits +will never be returned from the commit-graph at the cost of performance. + +`GIT_ALLOW_PROTOCOL`:: + If set to a colon-separated list of protocols, behave as if + `protocol.allow` is set to `never`, and each of the listed + protocols has `protocol..allow` set to `always` + (overriding any existing configuration). See the description of + `protocol.allow` in linkgit:git-config[1] for more details. + +`GIT_PROTOCOL_FROM_USER`:: + Set this Boolean environment variable to false to prevent protocols used by fetch/push/clone which are + configured to the `user` state. This is useful to restrict recursive + submodule initialization from an untrusted repository or for programs + which feed potentially-untrusted URLS to git commands. See + linkgit:git-config[1] for more details. + +`GIT_PROTOCOL`:: + For internal use only. Used in handshaking the wire protocol. + Contains a colon ':' separated list of keys with optional values + '[=]'. Presence of unknown keys and values must be + ignored. ++ +Note that servers may need to be configured to allow this variable to +pass over some transports. It will be propagated automatically when +accessing local repositories (i.e., `file://` or a filesystem path), as +well as over the `git://` protocol. For git-over-http, it should work +automatically in most configurations, but see the discussion in +linkgit:git-http-backend[1]. For git-over-ssh, the ssh server may need +to be configured to allow clients to pass this variable (e.g., by using +`AcceptEnv GIT_PROTOCOL` with OpenSSH). ++ +This configuration is optional. If the variable is not propagated, then +clients will fall back to the original "v0" protocol (but may miss out +on some performance improvements or features). This variable currently +only affects clones and fetches; it is not yet used for pushes (but may +be in the future). + +`GIT_OPTIONAL_LOCKS`:: + If this Boolean environment variable is set to false, Git will complete any requested operation without + performing any optional sub-operations that require taking a lock. + For example, this will prevent `git status` from refreshing the + index as a side effect. This is useful for processes running in + the background which do not want to cause lock contention with + other operations on the repository. Defaults to `1`. + +`GIT_REDIRECT_STDIN`:: +`GIT_REDIRECT_STDOUT`:: +`GIT_REDIRECT_STDERR`:: + Windows-only: allow redirecting the standard input/output/error + handles to paths specified by the environment variables. This is + particularly useful in multi-threaded applications where the + canonical way to pass standard handles via `CreateProcess()` is + not an option because it would require the handles to be marked + inheritable (and consequently *every* spawned process would + inherit them, possibly blocking regular Git operations). The + primary intended use case is to use named pipes for communication + (e.g. `\\.\pipe\my-git-stdin-123`). ++ +Two special values are supported: `off` will simply close the +corresponding standard handle, and if `GIT_REDIRECT_STDERR` is +`2>&1`, standard error will be redirected to the same handle as +standard output. + +`GIT_PRINT_SHA1_ELLIPSIS` (deprecated):: + If set to `yes`, print an ellipsis following an + (abbreviated) SHA-1 value. This affects indications of + detached HEADs (linkgit:git-checkout[1]) and the raw + diff output (linkgit:git-diff[1]). Printing an + ellipsis in the cases mentioned is no longer considered + adequate and support for it is likely to be removed in the + foreseeable future (along with the variable). + +`GIT_ADVICE`:: + If set to `0`, then disable all advice messages. These messages are + intended to provide hints to human users that may help them get out of + problematic situations or take advantage of new features. Users can + disable individual messages using the `advice.*` config keys. These + messages may be disruptive to tools that execute Git processes, so this + variable is available to disable the messages. (The `--no-advice` + global option is also available, but old Git versions may fail when + this option is not understood. The environment variable will be ignored + by Git versions that do not understand it.) + +Discussion[[Discussion]] +------------------------ + +More detail on the following is available from the +link:/docs/user-manual#git-concepts[Git concepts chapter of the +user-manual] and linkgit:gitcore-tutorial[7]. + +A Git project normally consists of a working directory with a ".git" +subdirectory at the top level. The .git directory contains, among other +things, a compressed object database representing the complete history +of the project, an "index" file which links that history to the current +contents of the working tree, and named pointers into that history such +as tags and branch heads. + +The object database contains objects of three main types: blobs, which +hold file data; trees, which point to blobs and other trees to build up +directory hierarchies; and commits, which each reference a single tree +and some number of parent commits. + +The commit, equivalent to what other systems call a "changeset" or +"version", represents a step in the project's history, and each parent +represents an immediately preceding step. Commits with more than one +parent represent merges of independent lines of development. + +All objects are named by the SHA-1 hash of their contents, normally +written as a string of 40 hex digits. Such names are globally unique. +The entire history leading up to a commit can be vouched for by signing +just that commit. A fourth object type, the tag, is provided for this +purpose. + +When first created, objects are stored in individual files, but for +efficiency may later be compressed together into "pack files". + +Named pointers called refs mark interesting points in history. A ref +may contain the SHA-1 name of an object or the name of another ref (the +latter is called a "symbolic ref"). +Refs with names beginning `refs/head/` contain the SHA-1 name of the most +recent commit (or "head") of a branch under development. SHA-1 names of +tags of interest are stored under `refs/tags/`. A symbolic ref named +`HEAD` contains the name of the currently checked-out branch. + +The index file is initialized with a list of all paths and, for each +path, a blob object and a set of attributes. The blob object represents +the contents of the file as of the head of the current branch. The +attributes (last modified time, size, etc.) are taken from the +corresponding file in the working tree. Subsequent changes to the +working tree can be found by comparing these attributes. The index may +be updated with new content, and new commits may be created from the +content stored in the index. + +The index is also capable of storing multiple entries (called "stages") +for a given pathname. These stages are used to hold the various +unmerged version of a file when a merge is in progress. + +SECURITY +-------- + +Some configuration options and hook files may cause Git to run arbitrary +shell commands. Because configuration and hooks are not copied using +`git clone`, it is generally safe to clone remote repositories with +untrusted content, inspect them with `git log`, and so on. + +However, it is not safe to run Git commands in a `.git` directory (or +the working tree that surrounds it) when that `.git` directory itself +comes from an untrusted source. The commands in its config and hooks +are executed in the usual way. + +By default, Git will refuse to run when the repository is owned by +someone other than the user running the command. See the entry for +`safe.directory` in linkgit:git-config[1]. While this can help protect +you in a multi-user environment, note that you can also acquire +untrusted repositories that are owned by you (for example, if you +extract a zip file or tarball from an untrusted source). In such cases, +you'd need to "sanitize" the untrusted repository first. + +If you have an untrusted `.git` directory, you should first clone it +with `git clone --no-local` to obtain a clean copy. Git does restrict +the set of options and hooks that will be run by `upload-pack`, which +handles the server side of a clone or fetch, but beware that the +surface area for attack against `upload-pack` is large, so this does +carry some risk. The safest thing is to serve the repository as an +unprivileged user (either via linkgit:git-daemon[1], ssh, or using +other tools to change user ids). See the discussion in the `SECURITY` +section of linkgit:git-upload-pack[1]. + +FURTHER DOCUMENTATION +--------------------- + +See the references in the "description" section to get started +using Git. The following is probably more detail than necessary +for a first-time user. + +The link:/docs/user-manual#git-concepts[Git concepts chapter of the +user-manual] and linkgit:gitcore-tutorial[7] both provide +introductions to the underlying Git architecture. + +See linkgit:gitworkflows[7] for an overview of recommended workflows. + +See also the link:/docs/howto-index[howto] documents for some useful +examples. + +The internals are documented in the +link:/docs/api-index[Git API documentation]. + +Users migrating from CVS may also want to +read linkgit:gitcvs-migration[7]. + + +Authors +------- +Git was started by Linus Torvalds, and is currently maintained by Junio +C Hamano. Numerous contributions have come from the Git mailing list +. https://openhub.net/p/git/contributors/summary +gives you a more complete list of contributors. + +If you have a clone of git.git itself, the +output of linkgit:git-shortlog[1] and linkgit:git-blame[1] can show you +the authors for specific parts of the project. + +Reporting Bugs +-------------- + +Report bugs to the Git mailing list where the +development and maintenance is primarily done. You do not have to be +subscribed to the list to send a message there. See the list archive +at https://lore.kernel.org/git for previous bug reports and other +discussions. + +Issues which are security relevant should be disclosed privately to +the Git Security mailing list . + +SEE ALSO +-------- +linkgit:gittutorial[7], linkgit:gittutorial-2[7], +linkgit:giteveryday[7], linkgit:gitcvs-migration[7], +linkgit:gitglossary[7], linkgit:gitcore-tutorial[7], +linkgit:gitcli[7], link:/docs/user-manual[The Git User's Manual], +linkgit:gitworkflows[7] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/external/docs/content/docs/git-for-each-repo.html b/external/docs/content/docs/git-for-each-repo.html index 24a5df3321..fab0175914 100644 --- a/external/docs/content/docs/git-for-each-repo.html +++ b/external/docs/content/docs/git-for-each-repo.html @@ -6,8 +6,8 @@ subsection: manual title: Git - git-for-each-repo Documentation docname: git-for-each-repo -version: 2.46.0 -latest-changes: 2.46.0 +version: 2.45.3 +latest-changes: 2.45.3 aliases: - "/docs/git-for-each-repo/index.html" --- diff --git a/external/docs/content/docs/git-for-each-repo/2.46.0.html b/external/docs/content/docs/git-for-each-repo/2.46.0.html deleted file mode 100644 index 59e1ff7606..0000000000 --- a/external/docs/content/docs/git-for-each-repo/2.46.0.html +++ /dev/null @@ -1,113 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-docs.rb - -category: manual -section: documentation -subsection: manual -title: Git - git-for-each-repo Documentation -docname: git-for-each-repo -version: 2.46.0 -aliases: -- "/docs/git-for-each-repo/2.46.0/index.html" -- "/docs/git-for-each-repo/2.46.1/index.html" -- "/docs/git-for-each-repo/2.46.2/index.html" -- "/docs/git-for-each-repo/2.47.0/index.html" -- "/docs/git-for-each-repo/2.47.1/index.html" -- "/docs/git-for-each-repo/2.48.0/index.html" ---- -
-

NAME

-
-
-

git-for-each-repo - Run a Git command on a list of repositories

-
-
-
-
-

SYNOPSIS

-
-
-
git for-each-repo --config=<config> [--] <arguments>
-
-
-
-
-

DESCRIPTION

-
-
-

Run a Git command on a list of repositories. The arguments after the -known options or -- indicator are used as the arguments for the Git -subprocess.

-
-
-

THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.

-
-
-

For example, we could run maintenance on each of a list of repositories -stored in a maintenance.repo config variable using

-
-
-
-
git for-each-repo --config=maintenance.repo maintenance run
-
-
-
-

This will run git -C <repo> maintenance run for each value <repo> -in the multi-valued config variable maintenance.repo.

-
-
-
-
-

OPTIONS

-
-
-
-
--config=<config>
-
-

Use the given config variable as a multi-valued list storing -absolute path names. Iterate on that list of paths to run -the given arguments.

-
-

These config values are loaded from system, global, and local Git config, -as available. If git for-each-repo is run in a directory that is not a -Git repository, then only the system and global config is used.

-
-
-
--keep-going
-
-

Continue with the remaining repositories if the command failed -on a repository. The exit code will still indicate that the -overall operation was not successful.

-
-

Note that the exact exit code of the failing command is not passed -through as the exit code of the for-each-repo command: If the command -failed in any of the specified repositories, the overall exit code will -be 1.

-
-
-
-
-
-
-
-

SUBPROCESS BEHAVIOR

-
-
-

If any git -C <repo> <arguments> subprocess returns a non-zero exit code, -then the git for-each-repo process returns that exit code without running -more subprocesses.

-
-
-

Each git -C <repo> <arguments> subprocess inherits the standard file -descriptors stdin, stdout, and stderr.

-
-
-
-
-

GIT

-
-
-

Part of the git[1] suite

-
-
-
\ No newline at end of file diff --git a/external/docs/content/docs/git-gui.html b/external/docs/content/docs/git-gui.html index 3d398c7f67..de320d5a8b 100644 --- a/external/docs/content/docs/git-gui.html +++ b/external/docs/content/docs/git-gui.html @@ -6,8 +6,8 @@ subsection: manual title: Git - git-gui Documentation docname: git-gui -version: 2.46.0 -latest-changes: 2.46.0 +version: 2.45.3 +latest-changes: 2.45.3 aliases: - "/docs/git-gui/index.html" --- diff --git a/external/docs/content/docs/git-gui/2.46.0.html b/external/docs/content/docs/git-gui/2.46.0.html deleted file mode 100644 index 63da5cde5d..0000000000 --- a/external/docs/content/docs/git-gui/2.46.0.html +++ /dev/null @@ -1,186 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-docs.rb - -category: manual -section: documentation -subsection: manual -title: Git - git-gui Documentation -docname: git-gui -version: 2.46.0 -aliases: -- "/docs/git-gui/2.46.0/index.html" -- "/docs/git-gui/2.46.1/index.html" -- "/docs/git-gui/2.46.2/index.html" -- "/docs/git-gui/2.47.0/index.html" -- "/docs/git-gui/2.47.1/index.html" -- "/docs/git-gui/2.48.0/index.html" ---- -
-

NAME

-
-
-

git-gui - A portable graphical interface to Git

-
-
-
-
-

SYNOPSIS

-
-
-
git gui [<command>] [<arguments>]
-
-
-
-
-

DESCRIPTION

-
-
-

A Tcl/Tk based graphical user interface to Git. git gui focuses -on allowing users to make changes to their repository by making -new commits, amending existing ones, creating branches, performing -local merges, and fetching/pushing to remote repositories.

-
-
-

Unlike gitk, git gui focuses on commit generation -and single file annotation and does not show project history. -It does however supply menu actions to start a gitk session from -within git gui.

-
-
-

git gui is known to work on all popular UNIX systems, Mac OS X, -and Windows (under both Cygwin and MSYS). To the extent possible -OS specific user interface guidelines are followed, making git gui -a fairly native interface for users.

-
-
-
-
-

COMMANDS

-
-
-
-
blame
-
-

Start a blame viewer on the specified file on the given -version (or working directory if not specified).

-
-
browser
-
-

Start a tree browser showing all files in the specified -commit. Files selected through the -browser are opened in the blame viewer.

-
-
citool
-
-

Start git gui and arrange to make exactly one commit before -exiting and returning to the shell. The interface is limited -to only commit actions, slightly reducing the application’s -startup time and simplifying the menubar.

-
-
version
-
-

Display the currently running version of git gui.

-
-
-
-
-
-
-

Examples

-
-
-
-
git gui blame Makefile
-
-

Show the contents of the file Makefile in the current -working directory, and provide annotations for both the -original author of each line, and who moved the line to its -current location. The uncommitted file is annotated, and -uncommitted changes (if any) are explicitly attributed to -Not Yet Committed.

-
-
git gui blame v0.99.8 Makefile
-
-

Show the contents of Makefile in revision v0.99.8 -and provide annotations for each line. Unlike the above -example the file is read from the object database and not -the working directory.

-
-
git gui blame --line=100 Makefile
-
-

Loads annotations as described above and automatically -scrolls the view to center on line 100.

-
-
git gui citool
-
-

Make one commit and return to the shell when it is complete. -This command returns a non-zero exit code if the window was -closed in any way other than by making a commit.

-
-
git gui citool --amend
-
-

Automatically enter the Amend Last Commit mode of -the interface.

-
-
git gui citool --nocommit
-
-

Behave as normal citool, but instead of making a commit -simply terminate with a zero exit code. It still checks -that the index does not contain any unmerged entries, so -you can use it as a GUI version of git-mergetool[1]

-
-
git citool
-
-

Same as git gui citool (above).

-
-
git gui browser maint
-
-

Show a browser for the tree of the maint branch. Files -selected in the browser can be viewed with the internal -blame viewer.

-
-
-
-
-
-
-

SEE ALSO

-
-
-
-
gitk[1]
-
-

The Git repository browser. Shows branches, commit history -and file differences. gitk is the utility started by -git gui's Repository Visualize actions.

-
-
-
-
-
-
-

Other

-
-
-

git gui is actually maintained as an independent project, but stable -versions are distributed as part of the Git suite for the convenience -of end users.

-
-
-

The official repository of the git gui project can be found at:

-
-
-
-
https://github.com/j6t/git-gui
-
-
-
-
-
-

GIT

-
-
-

Part of the git[1] suite

-
-
-
\ No newline at end of file diff --git a/external/docs/content/docs/git-merge-tree/2.46.0.html b/external/docs/content/docs/git-merge-tree/2.46.0.html deleted file mode 100644 index 966c430346..0000000000 --- a/external/docs/content/docs/git-merge-tree/2.46.0.html +++ /dev/null @@ -1,475 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-docs.rb - -category: manual -section: documentation -subsection: manual -title: Git - git-merge-tree Documentation -docname: git-merge-tree -version: 2.46.0 -aliases: -- "/docs/git-merge-tree/2.46.0/index.html" -- "/docs/git-merge-tree/2.46.1/index.html" -- "/docs/git-merge-tree/2.46.2/index.html" -- "/docs/git-merge-tree/2.47.0/index.html" ---- -
-

NAME

-
-
-

git-merge-tree - Perform merge without touching index or working tree

-
-
-
-
-

SYNOPSIS

-
-
-
git merge-tree [--write-tree] [<options>] <branch1> <branch2>
-git merge-tree [--trivial-merge] <base-tree> <branch1> <branch2> (deprecated)
-
-
-
-
-

DESCRIPTION

-
-
-

This command has a modern --write-tree mode and a deprecated ---trivial-merge mode. With the exception of the -DEPRECATED DESCRIPTION section at the end, the rest of -this documentation describes the modern --write-tree mode.

-
-
-

Performs a merge, but does not make any new commits and does not read -from or write to either the working tree or index.

-
-
-

The performed merge will use the same features as the "real" -git-merge[1], including:

-
-
-
    -
  • -

    three way content merges of individual files

    -
    • -
  • -

    rename detection

    -
    • -
  • -

    proper directory/file conflict handling

    -
    • -
  • -

    recursive ancestor consolidation (i.e. when there is more than one -merge base, creating a virtual merge base by merging the merge bases)

    -
    • -
  • -

    etc.

    -
    • -
-
-
-

After the merge completes, a new toplevel tree object is created. See -OUTPUT below for details.

-
-
-
-
-

OPTIONS

-
-
-
-
-z
-
-

Do not quote filenames in the <Conflicted file info> section, -and end each filename with a NUL character rather than -newline. Also begin the messages section with a NUL character -instead of a newline. See OUTPUT below for more information.

-
-
--name-only
-
-

In the Conflicted file info section, instead of writing a list -of (mode, oid, stage, path) tuples to output for conflicted -files, just provide a list of filenames with conflicts (and -do not list filenames multiple times if they have multiple -conflicting stages).

-
-
--[no-]messages
-
-

Write any informational messages such as "Auto-merging <path>" -or CONFLICT notices to the end of stdout. If unspecified, the -default is to include these messages if there are merge -conflicts, and to omit them otherwise.

-
-
--allow-unrelated-histories
-
-

merge-tree will by default error out if the two branches specified -share no common history. This flag can be given to override that -check and make the merge proceed anyway.

-
-
--merge-base=<tree-ish>
-
-

Instead of finding the merge-bases for <branch1> and <branch2>, -specify a merge-base for the merge, and specifying multiple bases is -currently not supported. This option is incompatible with --stdin.

-
-

As the merge-base is provided directly, <branch1> and <branch2> do not need -to specify commits; trees are enough.

-
-
-
-X<option>
-
--strategy-option=<option>
-
-

Pass the merge strategy-specific option through to the merge strategy. -See git-merge[1] for details.

-
-
-
-
-
-
-

OUTPUT

-
-
-

For a successful merge, the output from git-merge-tree is simply one -line:

-
-
-
-
<OID of toplevel tree>
-
-
-
-

Whereas for a conflicted merge, the output is by default of the form:

-
-
-
-
<OID of toplevel tree>
-<Conflicted file info>
-<Informational messages>
-
-
-
-

These are discussed individually below.

-
-
-

However, there is an exception. If --stdin is passed, then there is -an extra section at the beginning, a NUL character at the end, and then -all the sections repeat for each line of input. Thus, if the first merge -is conflicted and the second is clean, the output would be of the form:

-
-
-
-
<Merge status>
-<OID of toplevel tree>
-<Conflicted file info>
-<Informational messages>
-NUL
-<Merge status>
-<OID of toplevel tree>
-NUL
-
-
-
-

Merge status

-
-

This is an integer status followed by a NUL character. The integer status is:

-
-
-
-
   0: merge had conflicts
-   1: merge was clean
-   <0: something prevented the merge from running (e.g. access to repository
-objects denied by filesystem)
-
-
-
-
-

OID of toplevel tree

-
-

This is a tree object that represents what would be checked out in the -working tree at the end of git merge. If there were conflicts, then -files within this tree may have embedded conflict markers. This section -is always followed by a newline (or NUL if -z is passed).

-
-
-
-

Conflicted file info

-
-

This is a sequence of lines with the format

-
-
-
-
<mode> <object> <stage> <filename>
-
-
-
-

The filename will be quoted as explained for the configuration -variable core.quotePath (see git-config[1]). However, if -the --name-only option is passed, the mode, object, and stage will -be omitted. If -z is passed, the "lines" are terminated by a NUL -character instead of a newline character.

-
-
-
-

Informational messages

-
-

This section provides informational messages, typically about -conflicts. The format of the section varies significantly depending -on whether -z is passed.

-
-
-

If -z is passed:

-
-
-

The output format is zero or more conflict informational records, each -of the form:

-
-
-
-
<list-of-paths><conflict-type>NUL<conflict-message>NUL
-
-
-
-

where <list-of-paths> is of the form

-
-
-
-
<number-of-paths>NUL<path1>NUL<path2>NUL...<pathN>NUL
-
-
-
-

and includes paths (or branch names) affected by the conflict or -informational message in <conflict-message>. Also, <conflict-type> is a -stable string explaining the type of conflict, such as

-
-
-
    -
  • -

    "Auto-merging"

    -
    • -
  • -

    "CONFLICT (rename/delete)"

    -
    • -
  • -

    "CONFLICT (submodule lacks merge base)"

    -
    • -
  • -

    "CONFLICT (binary)"

    -
    • -
-
-
-

and <conflict-message> is a more detailed message about the conflict which often -(but not always) embeds the <stable-short-type-description> within it. These -strings may change in future Git versions. Some examples:

-
-
-
    -
  • -

    "Auto-merging <file>"

    -
    • -
  • -

    "CONFLICT (rename/delete): <oldfile> renamed…​but deleted in…​"

    -
    • -
  • -

    "Failed to merge submodule <submodule> (no merge base)"

    -
    • -
  • -

    "Warning: cannot merge binary files: <filename>"

    -
    • -
-
-
-

If -z is NOT passed:

-
-
-

This section starts with a blank line to separate it from the previous -sections, and then only contains the <conflict-message> information -from the previous section (separated by newlines). These are -non-stable strings that should not be parsed by scripts, and are just -meant for human consumption. Also, note that while <conflict-message> -strings usually do not contain embedded newlines, they sometimes do. -(However, the free-form messages will never have an embedded NUL -character). So, the entire block of information is meant for human -readers as an agglomeration of all conflict messages.

-
-
-
-
-
-

EXIT STATUS

-
-
-

For a successful, non-conflicted merge, the exit status is 0. When the -merge has conflicts, the exit status is 1. If the merge is not able to -complete (or start) due to some kind of error, the exit status is -something other than 0 or 1 (and the output is unspecified). When ---stdin is passed, the return status is 0 for both successful and -conflicted merges, and something other than 0 or 1 if it cannot complete -all the requested merges.

-
-
-
-
-

USAGE NOTES

-
-
-

This command is intended as low-level plumbing, similar to -git-hash-object[1], git-mktree[1], -git-commit-tree[1], git-write-tree[1], -git-update-ref[1], and git-mktag[1]. Thus, it can be -used as a part of a series of steps such as:

-
-
-
-
NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2)
-test $? -eq 0 || die "There were conflicts..."
-NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 -p $BRANCH2)
-git update-ref $BRANCH1 $NEWCOMMIT
-
-
-
-

Note that when the exit status is non-zero, NEWTREE in this sequence -will contain a lot more output than just a tree.

-
-
-

For conflicts, the output includes the same information that you’d get -with git-merge[1]:

-
-
- -
-
-
-
-

INPUT FORMAT

-
-
-

git merge-tree --stdin input format is fully text based. Each line -has this format:

-
-
-
-
[<base-commit> -- ]<branch1> <branch2>
-
-
-
-

If one line is separated by --, the string before the separator is -used for specifying a merge-base for the merge and the string after -the separator describes the branches to be merged.

-
-
-
-
-

MISTAKES TO AVOID

-
-
-

Do NOT look through the resulting toplevel tree to try to find which -files conflict; parse the Conflicted file info section instead. -Not only would parsing an entire tree be horrendously slow in large -repositories, there are numerous types of conflicts not representable by -conflict markers (modify/delete, mode conflict, binary file changed on -both sides, file/directory conflicts, various rename conflict -permutations, etc.)

-
-
-

Do NOT interpret an empty Conflicted file info list as a clean -merge; check the exit status. A merge can have conflicts without having -individual files conflict (there are a few types of directory rename -conflicts that fall into this category, and others might also be added -in the future).

-
-
-

Do NOT attempt to guess or make the user guess the conflict types from -the Conflicted file info list. The information there is -insufficient to do so. For example: Rename/rename(1to2) conflicts (both -sides renamed the same file differently) will result in three different -files having higher order stages (but each only has one higher order -stage), with no way (short of the Informational messages section) -to determine which three files are related. File/directory conflicts -also result in a file with exactly one higher order stage. -Possibly-involved-in-directory-rename conflicts (when -"merge.directoryRenames" is unset or set to "conflicts") also result in -a file with exactly one higher order stage. In all cases, the -Informational messages section has the necessary info, though it -is not designed to be machine parseable.

-
-
-

Do NOT assume that each path from Conflicted file info, and -the logical conflicts in the Informational messages have a -one-to-one mapping, nor that there is a one-to-many mapping, nor a -many-to-one mapping. Many-to-many mappings exist, meaning that each -path can have many logical conflict types in a single merge, and each -logical conflict type can affect many paths.

-
-
-

Do NOT assume all filenames listed in the Informational messages -section had conflicts. Messages can be included for files that have no -conflicts, such as "Auto-merging <file>".

-
-
-

AVOID taking the OIDS from the Conflicted file info and -re-merging them to present the conflicts to the user. This will lose -information. Instead, look up the version of the file found within the -OID of toplevel tree and show that instead. In particular, -the latter will have conflict markers annotated with the original -branch/commit being merged and, if renames were involved, the original -filename. While you could include the original branch/commit in the -conflict marker annotations when re-merging, the original filename is -not available from the Conflicted file info and thus you would -be losing information that might help the user resolve the conflict.

-
-
-
-
-

DEPRECATED DESCRIPTION

-
-
-

Per the DESCRIPTION and unlike the rest of this -documentation, this section describes the deprecated --trivial-merge -mode.

-
-
-

Other than the optional --trivial-merge, this mode accepts no -options.

-
-
-

This mode reads three tree-ish, and outputs trivial merge results and -conflicting stages to the standard output in a semi-diff format. -Since this was designed for higher level scripts to consume and merge -the results back into the index, it omits entries that match -<branch1>. The result of this second form is similar to what -three-way git read-tree -m does, but instead of storing the results -in the index, the command outputs the entries to the standard output.

-
-
-

This form not only has limited applicability (a trivial merge cannot -handle content merges of individual files, rename detection, proper -directory/file conflict handling, etc.), the output format is also -difficult to work with, and it will generally be less performant than -the first form even on successful merges (especially if working in -large repositories).

-
-
-
-
-

GIT

-
-
-

Part of the git[1] suite

-
-
-
\ No newline at end of file diff --git a/external/docs/content/docs/git-rev-parse.html b/external/docs/content/docs/git-rev-parse.html index a5d486450d..1278ef6703 100644 --- a/external/docs/content/docs/git-rev-parse.html +++ b/external/docs/content/docs/git-rev-parse.html @@ -6,8 +6,8 @@ subsection: manual title: Git - git-rev-parse Documentation docname: git-rev-parse -version: 2.46.0 -latest-changes: 2.46.0 +version: 2.45.3 +latest-changes: 2.45.3 aliases: - "/docs/git-rev-parse/index.html" --- diff --git a/external/docs/content/docs/git-rev-parse/2.46.0.html b/external/docs/content/docs/git-rev-parse/2.46.0.html deleted file mode 100644 index e0a38edc82..0000000000 --- a/external/docs/content/docs/git-rev-parse/2.46.0.html +++ /dev/null @@ -1,1235 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-docs.rb - -category: manual -section: documentation -subsection: manual -title: Git - git-rev-parse Documentation -docname: git-rev-parse -version: 2.46.0 -aliases: -- "/docs/git-rev-parse/2.46.0/index.html" -- "/docs/git-rev-parse/2.46.1/index.html" -- "/docs/git-rev-parse/2.46.2/index.html" -- "/docs/git-rev-parse/2.47.0/index.html" -- "/docs/git-rev-parse/2.47.1/index.html" -- "/docs/git-rev-parse/2.48.0/index.html" ---- -
-

NAME

-
-
-

git-rev-parse - Pick out and massage parameters

-
-
-
-
-

SYNOPSIS

-
-
-
git rev-parse [<options>] <arg>…​
-
-
-
-
-

DESCRIPTION

-
-
-

Many Git porcelainish commands take a mixture of flags -(i.e. parameters that begin with a dash -) and parameters -meant for the underlying git rev-list command they use internally -and flags and parameters for the other commands they use -downstream of git rev-list. The primary purpose of this command -is to allow calling programs to distinguish between them. There are -a few other operation modes that have nothing to do with the above -"help parse command line options".

-
-
-

Unless otherwise specified, most of the options and operation modes -require you to run this command inside a git repository or a working -tree that is under the control of a git repository, and will give you -a fatal error otherwise.

-
-
-
-
-

OPTIONS

-
-
-

Operation Modes

-
-

Each of these options must appear first on the command line.

-
-
-
-
--parseopt
-
-

Use git rev-parse in option parsing mode (see PARSEOPT section below). -The command in this mode can be used outside a repository or -a working tree controlled by a repository.

-
-
--sq-quote
-
-

Use git rev-parse in shell quoting mode (see SQ-QUOTE -section below). In contrast to the --sq option below, this -mode only does quoting. Nothing else is done to command input. -The command in this mode can be used outside a repository or -a working tree controlled by a repository.

-
-
-
-
-
-

Options for --parseopt

-
-
-
--keep-dashdash
-
-

Only meaningful in --parseopt mode. Tells the option parser to echo -out the first -- met instead of skipping it.

-
-
--stop-at-non-option
-
-

Only meaningful in --parseopt mode. Lets the option parser stop at -the first non-option argument. This can be used to parse sub-commands -that take options themselves.

-
-
--stuck-long
-
-

Only meaningful in --parseopt mode. Output the options in their -long form if available, and with their arguments stuck.

-
-
-
-
-
-

Options for Filtering

-
-
-
--revs-only
-
-

Do not output flags and parameters not meant for -git rev-list command.

-
-
--no-revs
-
-

Do not output flags and parameters meant for -git rev-list command.

-
-
--flags
-
-

Do not output non-flag parameters.

-
-
--no-flags
-
-

Do not output flag parameters.

-
-
-
-
-
-

Options for Output

-
-
-
--default <arg>
-
-

If there is no parameter given by the user, use <arg> -instead.

-
-
--prefix <arg>
-
-

Behave as if git rev-parse was invoked from the <arg> -subdirectory of the working tree. Any relative filenames are -resolved as if they are prefixed by <arg> and will be printed -in that form.

-
-

This can be used to convert arguments to a command run in a subdirectory -so that they can still be used after moving to the top-level of the -repository. For example:

-
-
-
-
prefix=$(git rev-parse --show-prefix)
-cd "$(git rev-parse --show-toplevel)"
-# rev-parse provides the -- needed for 'set'
-eval "set $(git rev-parse --sq --prefix "$prefix" -- "$@")"
-
-
-
-
--verify
-
-

Verify that exactly one parameter is provided, and that it -can be turned into a raw 20-byte SHA-1 that can be used to -access the object database. If so, emit it to the standard -output; otherwise, error out.

-
-

If you want to make sure that the output actually names an object in -your object database and/or can be used as a specific type of object -you require, you can add the ^{type} peeling operator to the parameter. -For example, git rev-parse "$VAR^{commit}" will make sure $VAR -names an existing object that is a commit-ish (i.e. a commit, or an -annotated tag that points at a commit). To make sure that $VAR -names an existing object of any type, git rev-parse "$VAR^{object}" -can be used.

-
-
-

Note that if you are verifying a name from an untrusted source, it is -wise to use --end-of-options so that the name argument is not mistaken -for another option.

-
-
-
-q
-
--quiet
-
-

Only meaningful in --verify mode. Do not output an error -message if the first argument is not a valid object name; -instead exit with non-zero status silently. -SHA-1s for valid object names are printed to stdout on success.

-
-
--sq
-
-

Usually the output is made one line per flag and -parameter. This option makes output a single line, -properly quoted for consumption by shell. Useful when -you expect your parameter to contain whitespaces and -newlines (e.g. when using pickaxe -S with -git diff-*). In contrast to the --sq-quote option, -the command input is still interpreted as usual.

-
-
--short[=<length>]
-
-

Same as --verify but shortens the object name to a unique -prefix with at least length characters. The minimum length -is 4, the default is the effective value of the core.abbrev -configuration variable (see git-config[1]).

-
-
--not
-
-

When showing object names, prefix them with ^ and -strip ^ prefix from the object names that already have -one.

-
-
--abbrev-ref[=(strict|loose)]
-
-

A non-ambiguous short name of the objects name. -The option core.warnAmbiguousRefs is used to select the strict -abbreviation mode.

-
-
--symbolic
-
-

Usually the object names are output in SHA-1 form (with -possible ^ prefix); this option makes them output in a -form as close to the original input as possible.

-
-
--symbolic-full-name
-
-

This is similar to --symbolic, but it omits input that -are not refs (i.e. branch or tag names; or more -explicitly disambiguating "heads/master" form, when you -want to name the "master" branch when there is an -unfortunately named tag "master"), and shows them as full -refnames (e.g. "refs/heads/master").

-
-
--output-object-format=(sha1|sha256|storage)
-
-

Allow oids to be input from any object format that the current -repository supports.

-
-
-
Specifying "sha1" translates if necessary and returns a sha1 oid.
-
-
-
-
-
Specifying "sha256" translates if necessary and returns a sha256 oid.
-
-
-
-
-
Specifying "storage" translates if necessary and returns an oid in
-encoded in the storage hash algorithm.
-
-
-
-
-
-
-
-

Options for Objects

-
-
-
--all
-
-

Show all refs found in refs/.

-
-
--branches[=<pattern>]
-
--tags[=<pattern>]
-
--remotes[=<pattern>]
-
-

Show all branches, tags, or remote-tracking branches, -respectively (i.e., refs found in refs/heads, -refs/tags, or refs/remotes, respectively).

-
-

If a pattern is given, only refs matching the given shell glob are -shown. If the pattern does not contain a globbing character (?, -*, or [), it is turned into a prefix match by appending /*.

-
-
-
--glob=<pattern>
-
-

Show all refs matching the shell glob pattern pattern. If -the pattern does not start with refs/, this is automatically -prepended. If the pattern does not contain a globbing -character (?, *, or [), it is turned into a prefix -match by appending /*.

-
-
--exclude=<glob-pattern>
-
-

Do not include refs matching <glob-pattern> that the next --all, ---branches, --tags, --remotes, or --glob would otherwise -consider. Repetitions of this option accumulate exclusion patterns -up to the next --all, --branches, --tags, --remotes, or ---glob option (other options or arguments do not clear -accumulated patterns).

-
-

The patterns given should not begin with refs/heads, refs/tags, or -refs/remotes when applied to --branches, --tags, or --remotes, -respectively, and they must begin with refs/ when applied to --glob -or --all. If a trailing /* is intended, it must be given -explicitly.

-
-
-
--exclude-hidden=(fetch|receive|uploadpack)
-
-

Do not include refs that would be hidden by git-fetch, -git-receive-pack or git-upload-pack by consulting the appropriate -fetch.hideRefs, receive.hideRefs or uploadpack.hideRefs -configuration along with transfer.hideRefs (see -git-config[1]). This option affects the next pseudo-ref option ---all or --glob and is cleared after processing them.

-
-
--disambiguate=<prefix>
-
-

Show every object whose name begins with the given prefix. -The <prefix> must be at least 4 hexadecimal digits long to -avoid listing each and every object in the repository by -mistake.

-
-
-
-
-
-

Options for Files

-
-
-
--local-env-vars
-
-

List the GIT_* environment variables that are local to the -repository (e.g. GIT_DIR or GIT_WORK_TREE, but not GIT_EDITOR). -Only the names of the variables are listed, not their value, -even if they are set.

-
-
--path-format=(absolute|relative)
-
-

Controls the behavior of certain other options. If specified as absolute, the -paths printed by those options will be absolute and canonical. If specified as -relative, the paths will be relative to the current working directory if that -is possible. The default is option specific.

-
-

This option may be specified multiple times and affects only the arguments that -follow it on the command line, either to the end of the command line or the next -instance of this option.

-
-
-
-
-
-

The following options are modified by --path-format:

-
-
-
-
--git-dir
-
-

Show $GIT_DIR if defined. Otherwise show the path to -the .git directory. The path shown, when relative, is -relative to the current working directory.

-
-

If $GIT_DIR is not defined and the current directory -is not detected to lie in a Git repository or work tree -print a message to stderr and exit with nonzero status.

-
-
-
--git-common-dir
-
-

Show $GIT_COMMON_DIR if defined, else $GIT_DIR.

-
-
--resolve-git-dir <path>
-
-

Check if <path> is a valid repository or a gitfile that -points at a valid repository, and print the location of the -repository. If <path> is a gitfile then the resolved path -to the real repository is printed.

-
-
--git-path <path>
-
-

Resolve "$GIT_DIR/<path>" and takes other path relocation -variables such as $GIT_OBJECT_DIRECTORY, -$GIT_INDEX_FILE…​ into account. For example, if -$GIT_OBJECT_DIRECTORY is set to /foo/bar then "git rev-parse ---git-path objects/abc" returns /foo/bar/abc.

-
-
--show-toplevel
-
-

Show the (by default, absolute) path of the top-level directory -of the working tree. If there is no working tree, report an error.

-
-
--show-superproject-working-tree
-
-

Show the absolute path of the root of the superproject’s -working tree (if exists) that uses the current repository as -its submodule. Outputs nothing if the current repository is -not used as a submodule by any project.

-
-
--shared-index-path
-
-

Show the path to the shared index file in split index mode, or -empty if not in split-index mode.

-
-
-
-
-

The following options are unaffected by --path-format:

-
-
-
-
--absolute-git-dir
-
-

Like --git-dir, but its output is always the canonicalized -absolute path.

-
-
--is-inside-git-dir
-
-

When the current working directory is below the repository -directory print "true", otherwise "false".

-
-
--is-inside-work-tree
-
-

When the current working directory is inside the work tree of the -repository print "true", otherwise "false".

-
-
--is-bare-repository
-
-

When the repository is bare print "true", otherwise "false".

-
-
--is-shallow-repository
-
-

When the repository is shallow print "true", otherwise "false".

-
-
--show-cdup
-
-

When the command is invoked from a subdirectory, show the -path of the top-level directory relative to the current -directory (typically a sequence of "../", or an empty string).

-
-
--show-prefix
-
-

When the command is invoked from a subdirectory, show the -path of the current directory relative to the top-level -directory.

-
-
--show-object-format[=(storage|input|output)]
-
-

Show the object format (hash algorithm) used for the repository -for storage inside the .git directory, input, or output. For -input, multiple algorithms may be printed, space-separated. -If not specified, the default is "storage".

-
-
--show-ref-format
-
-

Show the reference storage format used for the repository.

-
-
-
-
-
-

Other Options

-
-
-
--since=<datestring>
-
--after=<datestring>
-
-

Parse the date string, and output the corresponding ---max-age= parameter for git rev-list.

-
-
--until=<datestring>
-
--before=<datestring>
-
-

Parse the date string, and output the corresponding ---min-age= parameter for git rev-list.

-
-
<arg>…​
-
-

Flags and parameters to be parsed.

-
-
-
-
-
-
-
-

SPECIFYING REVISIONS

-
-
-

A revision parameter <rev> typically, but not necessarily, names a -commit object. It uses what is called an extended SHA-1 -syntax. Here are various ways to spell object names. The -ones listed near the end of this list name trees and -blobs contained in a commit.

-
-
- - - - - -
-
Note
-		 -This document shows the "raw" syntax as seen by git. The shell -and other UIs might require additional quoting to protect special -characters and to avoid word splitting. -
-
-
-
-
<sha1>, e.g. dae86e1950b1277e545cee180551750029cfe735, dae86e
-
-

The full SHA-1 object name (40-byte hexadecimal string), or -a leading substring that is unique within the repository. -E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both -name the same commit object if there is no other object in -your repository whose object name starts with dae86e.

-
-
<describeOutput>, e.g. v1.7.4.2-679-g3bee7fb
-
-

Output from git describe; i.e. a closest tag, optionally -followed by a dash and a number of commits, followed by a dash, a -g, and an abbreviated object name.

-
-
<refname>, e.g. master, heads/master, refs/heads/master
-
-

A symbolic ref name. E.g. master typically means the commit -object referenced by refs/heads/master. If you -happen to have both heads/master and tags/master, you can -explicitly say heads/master to tell Git which one you mean. -When ambiguous, a <refname> is disambiguated by taking the -first match in the following rules:

-
-
    -
  1. -

    If $GIT_DIR/<refname> exists, that is what you mean (this is usually -useful only for HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD, -REBASE_HEAD, REVERT_HEAD, CHERRY_PICK_HEAD, BISECT_HEAD -and AUTO_MERGE);

    -
    2. -
  2. -

    otherwise, refs/<refname> if it exists;

    -
    3. -
  3. -

    otherwise, refs/tags/<refname> if it exists;

    -
    4. -
  4. -

    otherwise, refs/heads/<refname> if it exists;

    -
    5. -
  5. -

    otherwise, refs/remotes/<refname> if it exists;

    -
    6. -
  6. -

    otherwise, refs/remotes/<refname>/HEAD if it exists.

    -
    -
    -
    HEAD
    -
    -

    names the commit on which you based the changes in the working tree.

    -
    -
    FETCH_HEAD
    -
    -

    records the branch which you fetched from a remote repository with -your last git fetch invocation.

    -
    -
    ORIG_HEAD
    -
    -

    is created by commands that move your HEAD in a drastic way (git -am, git merge, git rebase, git reset), to record the position -of the HEAD before their operation, so that you can easily change -the tip of the branch back to the state before you ran them.

    -
    -
    MERGE_HEAD
    -
    -

    records the commit(s) which you are merging into your branch when you -run git merge.

    -
    -
    REBASE_HEAD
    -
    -

    during a rebase, records the commit at which the operation is -currently stopped, either because of conflicts or an edit command in -an interactive rebase.

    -
    -
    REVERT_HEAD
    -
    -

    records the commit which you are reverting when you run git revert.

    -
    -
    CHERRY_PICK_HEAD
    -
    -

    records the commit which you are cherry-picking when you run git -cherry-pick.

    -
    -
    BISECT_HEAD
    -
    -

    records the current commit to be tested when you run git bisect ---no-checkout.

    -
    -
    AUTO_MERGE
    -
    -

    records a tree object corresponding to the state the -ort merge strategy wrote to the working tree when a merge operation -resulted in conflicts.

    -
    -
    -
    -
    7. -
-
-
-

Note that any of the refs/* cases above may come either from -the $GIT_DIR/refs directory or from the $GIT_DIR/packed-refs file. -While the ref name encoding is unspecified, UTF-8 is preferred as -some output processing may assume ref names in UTF-8.

-
-
-
@
-
-

@ alone is a shortcut for HEAD.

-
-
[<refname>]@{<date>}, e.g. master@{yesterday}, HEAD@{5 minutes ago}
-
-

A ref followed by the suffix @ with a date specification -enclosed in a brace -pair (e.g. {yesterday}, {1 month 2 weeks 3 days 1 hour 1 -second ago} or {1979-02-26 18:30:00}) specifies the value -of the ref at a prior point in time. This suffix may only be -used immediately following a ref name and the ref must have an -existing log ($GIT_DIR/logs/<ref>). Note that this looks up the state -of your local ref at a given time; e.g., what was in your local -master branch last week. If you want to look at commits made during -certain times, see --since and --until.

-
-
<refname>@{<n>}, e.g. master@{1}
-
-

A ref followed by the suffix @ with an ordinal specification -enclosed in a brace pair (e.g. {1}, {15}) specifies -the n-th prior value of that ref. For example master@{1} -is the immediate prior value of master while master@{5} -is the 5th prior value of master. This suffix may only be used -immediately following a ref name and the ref must have an existing -log ($GIT_DIR/logs/<refname>).

-
-
@{<n>}, e.g. @{1}
-
-

You can use the @ construct with an empty ref part to get at a -reflog entry of the current branch. For example, if you are on -branch blabla then @{1} means the same as blabla@{1}.

-
-
@{-<n>}, e.g. @{-1}
-
-

The construct @{-<n>} means the <n>th branch/commit checked out -before the current one.

-
-
[<branchname>]@{upstream}, e.g. master@{upstream}, @{u}
-
-

A branch B may be set up to build on top of a branch X (configured with -branch.<name>.merge) at a remote R (configured with -branch.<name>.remote). B@{u} refers to the remote-tracking branch for -the branch X taken from remote R, typically found at refs/remotes/R/X.

-
-
[<branchname>]@{push}, e.g. master@{push}, @{push}
-
-

The suffix @{push} reports the branch "where we would push to" if -git push were run while branchname was checked out (or the current -HEAD if no branchname is specified). Like for @{upstream}, we report -the remote-tracking branch that corresponds to that branch at the remote.

-
-

Here’s an example to make it more clear:

-
-
-
-
$ git config push.default current
-$ git config remote.pushdefault myfork
-$ git switch -c mybranch origin/master
-
-$ git rev-parse --symbolic-full-name @{upstream}
-refs/remotes/origin/master
-
-$ git rev-parse --symbolic-full-name @{push}
-refs/remotes/myfork/mybranch
-
-
-
-

Note in the example that we set up a triangular workflow, where we pull -from one location and push to another. In a non-triangular workflow, -@{push} is the same as @{upstream}, and there is no need for it.

-
-
-

This suffix is also accepted when spelled in uppercase, and means the same -thing no matter the case.

-
-
-
<rev>^[<n>], e.g. HEAD^, v1.5.1^0
-
-

A suffix ^ to a revision parameter means the first parent of -that commit object. ^<n> means the <n>th parent (i.e. -<rev>^ -is equivalent to <rev>^1). As a special rule, -<rev>^0 means the commit itself and is used when <rev> is the -object name of a tag object that refers to a commit object.

-
-
<rev>~[<n>], e.g. HEAD~, master~3
-
-

A suffix ~ to a revision parameter means the first parent of -that commit object. -A suffix ~<n> to a revision parameter means the commit -object that is the <n>th generation ancestor of the named -commit object, following only the first parents. I.e. <rev>~3 is -equivalent to <rev>^^^ which is equivalent to -<rev>^1^1^1. See below for an illustration of -the usage of this form.

-
-
<rev>^{<type>}, e.g. v0.99.8^{commit}
-
-

A suffix ^ followed by an object type name enclosed in -brace pair means dereference the object at <rev> recursively until -an object of type <type> is found or the object cannot be -dereferenced anymore (in which case, barf). -For example, if <rev> is a commit-ish, <rev>^{commit} -describes the corresponding commit object. -Similarly, if <rev> is a tree-ish, <rev>^{tree} -describes the corresponding tree object. -<rev>^0 -is a short-hand for <rev>^{commit}.

-
-

<rev>^{object} can be used to make sure <rev> names an -object that exists, without requiring <rev> to be a tag, and -without dereferencing <rev>; because a tag is already an object, -it does not have to be dereferenced even once to get to an object.

-
-
-

<rev>^{tag} can be used to ensure that <rev> identifies an -existing tag object.

-
-
-
<rev>^{}, e.g. v0.99.8^{}
-
-

A suffix ^ followed by an empty brace pair -means the object could be a tag, -and dereference the tag recursively until a non-tag object is -found.

-
-
<rev>^{/<text>}, e.g. HEAD^{/fix nasty bug}
-
-

A suffix ^ to a revision parameter, followed by a brace -pair that contains a text led by a slash, -is the same as the :/fix nasty bug syntax below except that -it returns the youngest matching commit which is reachable from -the <rev> before ^.

-
-
:/<text>, e.g. :/fix nasty bug
-
-

A colon, followed by a slash, followed by a text, names -a commit whose commit message matches the specified regular expression. -This name returns the youngest matching commit which is -reachable from any ref, including HEAD. -The regular expression can match any part of the -commit message. To match messages starting with a string, one can use -e.g. :/^foo. The special sequence :/! is reserved for modifiers to what -is matched. :/!-foo performs a negative match, while :/!!foo matches a -literal ! character, followed by foo. Any other sequence beginning with -:/! is reserved for now. -Depending on the given text, the shell’s word splitting rules might -require additional quoting.

-
-
<rev>:<path>, e.g. HEAD:README, master:./README
-
-

A suffix : followed by a path names the blob or tree -at the given path in the tree-ish object named by the part -before the colon. -A path starting with ./ or ../ is relative to the current working directory. -The given path will be converted to be relative to the working tree’s root directory. -This is most useful to address a blob or tree from a commit or tree that has -the same tree structure as the working tree.

-
-
:[<n>:]<path>, e.g. :0:README, :README
-
-

A colon, optionally followed by a stage number (0 to 3) and a -colon, followed by a path, names a blob object in the -index at the given path. A missing stage number (and the colon -that follows it) names a stage 0 entry. During a merge, stage -1 is the common ancestor, stage 2 is the target branch’s version -(typically the current branch), and stage 3 is the version from -the branch which is being merged.

-
-
-
-
-

Here is an illustration, by Jon Loeliger. Both commit nodes B -and C are parents of commit node A. Parent commits are ordered -left-to-right.

-
-
-
-
G   H   I   J
- \ /     \ /
-  D   E   F
-   \  |  / \
-    \ | /   |
-     \|/    |
-      B     C
-       \   /
-        \ /
-         A
-
-
-
-
-
A =      = A^0
-B = A^   = A^1     = A~1
-C =      = A^2
-D = A^^  = A^1^1   = A~2
-E = B^2  = A^^2
-F = B^3  = A^^3
-G = A^^^ = A^1^1^1 = A~3
-H = D^2  = B^^2    = A^^^2  = A~2^2
-I = F^   = B^3^    = A^^3^
-J = F^2  = B^3^2   = A^^3^2
-
-
-
-
-
-

SPECIFYING RANGES

-
-
-

History traversing commands such as git log operate on a set -of commits, not just a single commit.

-
-
-

For these commands, -specifying a single revision, using the notation described in the -previous section, means the set of commits reachable from the given -commit.

-
-
-

Specifying several revisions means the set of commits reachable from -any of the given commits.

-
-
-

A commit’s reachable set is the commit itself and the commits in -its ancestry chain.

-
-
-

There are several notations to specify a set of connected commits -(called a "revision range"), illustrated below.

-
-
-

Commit Exclusions

-
-
-
^<rev> (caret) Notation
-
-

To exclude commits reachable from a commit, a prefix ^ -notation is used. E.g. ^r1 r2 means commits reachable -from r2 but exclude the ones reachable from r1 (i.e. r1 and -its ancestors).

-
-
-
-
-
-

Dotted Range Notations

-
-
-
The .. (two-dot) Range Notation
-
-

The ^r1 r2 set operation appears so often that there is a shorthand -for it. When you have two commits r1 and r2 (named according -to the syntax explained in SPECIFYING REVISIONS above), you can ask -for commits that are reachable from r2 excluding those that are reachable -from r1 by ^r1 r2 and it can be written as r1..r2.

-
-
The ... (three-dot) Symmetric Difference Notation
-
-

A similar notation r1...r2 is called symmetric difference -of r1 and r2 and is defined as -r1 r2 --not $(git merge-base --all r1 r2). -It is the set of commits that are reachable from either one of -r1 (left side) or r2 (right side) but not from both.

-
-
-
-
-

In these two shorthand notations, you can omit one end and let it default to HEAD. -For example, origin.. is a shorthand for origin..HEAD and asks "What -did I do since I forked from the origin branch?" Similarly, ..origin -is a shorthand for HEAD..origin and asks "What did the origin do since -I forked from them?" Note that .. would mean HEAD..HEAD which is an -empty range that is both reachable and unreachable from HEAD.

-
-
-

Commands that are specifically designed to take two distinct ranges -(e.g. "git range-diff R1 R2" to compare two ranges) do exist, but -they are exceptions. Unless otherwise noted, all "git" commands -that operate on a set of commits work on a single revision range. -In other words, writing two "two-dot range notation" next to each -other, e.g.

-
-
-
-
$ git log A..B C..D
-
-
-
-

does not specify two revision ranges for most commands. Instead -it will name a single connected set of commits, i.e. those that are -reachable from either B or D but are reachable from neither A or C. -In a linear history like this:

-
-
-
-
---A---B---o---o---C---D
-
-
-
-

because A and B are reachable from C, the revision range specified -by these two dotted ranges is a single commit D.

-
-
-
-

Other <rev>^ Parent Shorthand Notations

-
-

Three other shorthands exist, particularly useful for merge commits, -for naming a set that is formed by a commit and its parent commits.

-
-
-

The r1^@ notation means all parents of r1.

-
-
-

The r1^! notation includes commit r1 but excludes all of its parents. -By itself, this notation denotes the single commit r1.

-
-
-

The <rev>^-[<n>] notation includes <rev> but excludes the <n>th -parent (i.e. a shorthand for <rev>^<n>..<rev>), with <n> = 1 if -not given. This is typically useful for merge commits where you -can just pass <commit>^- to get all the commits in the branch -that was merged in merge commit <commit> (including <commit> -itself).

-
-
-

While <rev>^<n> was about specifying a single commit parent, these -three notations also consider its parents. For example you can say -HEAD^2^@, however you cannot say HEAD^@^2.

-
-
-
-
-
-

Revision Range Summary

-
-
-
-
<rev>
-
-

Include commits that are reachable from <rev> (i.e. <rev> and its -ancestors).

-
-
^<rev>
-
-

Exclude commits that are reachable from <rev> (i.e. <rev> and its -ancestors).

-
-
<rev1>..<rev2>
-
-

Include commits that are reachable from <rev2> but exclude -those that are reachable from <rev1>. When either <rev1> or -<rev2> is omitted, it defaults to HEAD.

-
-
<rev1>...<rev2>
-
-

Include commits that are reachable from either <rev1> or -<rev2> but exclude those that are reachable from both. When -either <rev1> or <rev2> is omitted, it defaults to HEAD.

-
-
<rev>^@, e.g. HEAD^@
-
-

A suffix ^ followed by an at sign is the same as listing -all parents of <rev> (meaning, include anything reachable from -its parents, but not the commit itself).

-
-
<rev>^!, e.g. HEAD^!
-
-

A suffix ^ followed by an exclamation mark is the same -as giving commit <rev> and all its parents prefixed with -^ to exclude them (and their ancestors).

-
-
<rev>^-<n>, e.g. HEAD^-, HEAD^-2
-
-

Equivalent to <rev>^<n>..<rev>, with <n> = 1 if not -given.

-
-
-
-
-

Here are a handful of examples using the Loeliger illustration above, -with each step in the notation’s expansion and selection carefully -spelt out:

-
-
-
-
   Args   Expanded arguments    Selected commits
-   D                            G H D
-   D F                          G H I J D F
-   ^G D                         H D
-   ^D B                         E I J F B
-   ^D B C                       E I J F B C
-   C                            I J F C
-   B..C   = ^B C                C
-   B...C  = B ^F C              G H D E B C
-   B^-    = B^..B
-	  = ^B^1 B              E I J F B
-   C^@    = C^1
-	  = F                   I J F
-   B^@    = B^1 B^2 B^3
-	  = D E F               D G H E F I J
-   C^!    = C ^C^@
-	  = C ^C^1
-	  = C ^F                C
-   B^!    = B ^B^@
-	  = B ^B^1 ^B^2 ^B^3
-	  = B ^D ^E ^F          B
-   F^! D  = F ^I ^J D           G H D F
-
-
-
-
-
-

PARSEOPT

-
-
-

In --parseopt mode, git rev-parse helps massaging options to bring to shell -scripts the same facilities C builtins have. It works as an option normalizer -(e.g. splits single switches aggregate values), a bit like getopt(1) does.

-
-
-

It takes on the standard input the specification of the options to parse and -understand, and echoes on the standard output a string suitable for sh(1) eval -to replace the arguments with normalized ones. In case of error, it outputs -usage on the standard error stream, and exits with code 129.

-
-
-

Note: Make sure you quote the result when passing it to eval. See -below for an example.

-
-
-

Input Format

-
-

git rev-parse --parseopt input format is fully text based. It has two parts, -separated by a line that contains only --. The lines before the separator -(should be one or more) are used for the usage. -The lines after the separator describe the options.

-
-
-

Each line of options has this format:

-
-
-
-
<opt-spec><flags>*<arg-hint>? SP+ help LF
-
-
-
-
-
<opt-spec>
-
-

its format is the short option character, then the long option name -separated by a comma. Both parts are not required, though at least one -is necessary. May not contain any of the <flags> characters. -h,help, dry-run and f are examples of correct <opt-spec>.

-
-
<flags>
-
-

<flags> are of *, =, ? or !.

-
-
    -
  • -

    Use = if the option takes an argument.

    -
    • -
  • -

    Use ? to mean that the option takes an optional argument. You -probably want to use the --stuck-long mode to be able to -unambiguously parse the optional argument.

    -
    • -
  • -

    Use * to mean that this option should not be listed in the usage -generated for the -h argument. It’s shown for --help-all as -documented in gitcli[7].

    -
    • -
  • -

    Use ! to not make the corresponding negated long option available.

    -
    • -
-
-
-
<arg-hint>
-
-

<arg-hint>, if specified, is used as a name of the argument in the -help output, for options that take arguments. <arg-hint> is -terminated by the first whitespace. It is customary to use a -dash to separate words in a multi-word argument hint.

-
-
-
-
-

The remainder of the line, after stripping the spaces, is used -as the help associated with the option.

-
-
-

Blank lines are ignored, and lines that don’t match this specification are used -as option group headers (start the line with a space to create such -lines on purpose).

-
-
-
-

Example

-
-
-
OPTS_SPEC="\
-some-command [<options>] <args>...
-
-some-command does foo and bar!
---
-h,help!   show the help
-
-foo       some nifty option --foo
-bar=      some cool option --bar with an argument
-baz=arg   another cool option --baz with a named argument
-qux?path  qux may take a path argument but has meaning by itself
-
-  An option group Header
-C?        option C with an optional argument"
-
-eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"
-
-
-
-
-

Usage text

-
-

When "$@" is -h or --help in the above example, the following -usage text would be shown:

-
-
-
-
usage: some-command [<options>] <args>...
-
-    some-command does foo and bar!
-
-    -h, --help            show the help
-    --[no-]foo            some nifty option --foo
-    --[no-]bar ...        some cool option --bar with an argument
-    --[no-]baz <arg>      another cool option --baz with a named argument
-    --[no-]qux[=<path>]   qux may take a path argument but has meaning by itself
-
-An option group Header
-    -C[...]               option C with an optional argument
-
-
-
-
-
-
-

SQ-QUOTE

-
-
-

In --sq-quote mode, git rev-parse echoes on the standard output a -single line suitable for sh(1) eval. This line is made by -normalizing the arguments following --sq-quote. Nothing other than -quoting the arguments is done.

-
-
-

If you want command input to still be interpreted as usual by -git rev-parse before the output is shell quoted, see the --sq -option.

-
-
-

Example

-
-
-
$ cat >your-git-script.sh <<\EOF
-#!/bin/sh
-args=$(git rev-parse --sq-quote "$@")   # quote user-supplied arguments
-command="git frotz -n24 $args"          # and use it inside a handcrafted
-					# command line
-eval "$command"
-EOF
-
-$ sh your-git-script.sh "a b'c"
-
-
-
-
-
-
-

EXAMPLES

-
-
-
    -
  • -

    Print the object name of the current commit:

    -
    -
    -
    $ git rev-parse --verify HEAD
    -
    -
    -
    • -
  • -

    Print the commit object name from the revision in the $REV shell variable:

    -
    -
    -
    $ git rev-parse --verify --end-of-options $REV^{commit}
    -
    -
    -
    -

    This will error out if $REV is empty or not a valid revision.

    -
    -
    • -
  • -

    Similar to above:

    -
    -
    -
    $ git rev-parse --default master --verify --end-of-options $REV
    -
    -
    -
    -

    but if $REV is empty, the commit object name from master will be printed.

    -
    -
    • -
-
-
-
-
-

GIT

-
-
-

Part of the git[1] suite

-
-
-
\ No newline at end of file diff --git a/external/docs/content/docs/git-update-index.html b/external/docs/content/docs/git-update-index.html index b8c0ae1b52..fd7d9f264c 100644 --- a/external/docs/content/docs/git-update-index.html +++ b/external/docs/content/docs/git-update-index.html @@ -6,8 +6,8 @@ subsection: manual title: Git - git-update-index Documentation docname: git-update-index -version: 2.46.0 -latest-changes: 2.46.0 +version: 2.45.3 +latest-changes: 2.45.3 aliases: - "/docs/git-update-index/index.html" --- diff --git a/external/docs/content/docs/git-update-index/2.46.0.html b/external/docs/content/docs/git-update-index/2.46.0.html deleted file mode 100644 index cdcda3f70e..0000000000 --- a/external/docs/content/docs/git-update-index/2.46.0.html +++ /dev/null @@ -1,801 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-docs.rb - -category: manual -section: documentation -subsection: manual -title: Git - git-update-index Documentation -docname: git-update-index -version: 2.46.0 -aliases: -- "/docs/git-update-index/2.46.0/index.html" -- "/docs/git-update-index/2.46.1/index.html" -- "/docs/git-update-index/2.46.2/index.html" -- "/docs/git-update-index/2.47.0/index.html" -- "/docs/git-update-index/2.47.1/index.html" -- "/docs/git-update-index/2.48.0/index.html" ---- -
-

NAME

-
-
-

git-update-index - Register file contents in the working tree to the index

-
-
-
-
-

SYNOPSIS

-
-
-
git update-index
-	     [--add] [--remove | --force-remove] [--replace]
-	     [--refresh] [-q] [--unmerged] [--ignore-missing]
-	     [(--cacheinfo <mode>,<object>,<file>)…​]
-	     [--chmod=(+|-)x]
-	     [--[no-]assume-unchanged]
-	     [--[no-]skip-worktree]
-	     [--[no-]ignore-skip-worktree-entries]
-	     [--[no-]fsmonitor-valid]
-	     [--ignore-submodules]
-	     [--[no-]split-index]
-	     [--[no-|test-|force-]untracked-cache]
-	     [--[no-]fsmonitor]
-	     [--really-refresh] [--unresolve] [--again | -g]
-	     [--info-only] [--index-info]
-	     [-z] [--stdin] [--index-version <n>]
-	     [--show-index-version]
-	     [--verbose]
-	     [--] [<file>…​]
-
-
-
-
-

DESCRIPTION

-
-
-

Modifies the index. Each file mentioned is updated into the index and -any unmerged or needs updating state is cleared.

-
-
-

See also git-add[1] for a more user-friendly way to do some of -the most common operations on the index.

-
-
-

The way git update-index handles files it is told about can be modified -using the various options:

-
-
-
-
-

OPTIONS

-
-
-
-
--add
-
-

If a specified file isn’t in the index already then it’s -added. -Default behaviour is to ignore new files.

-
-
--remove
-
-

If a specified file is in the index but is missing then it’s -removed. -Default behavior is to ignore removed files.

-
-
--refresh
-
-

Looks at the current index and checks to see if merges or -updates are needed by checking stat() information.

-
-
-q
-
-

Quiet. If --refresh finds that the index needs an update, the - default behavior is to error out. This option makes -git update-index continue anyway.

-
-
--ignore-submodules
-
-

Do not try to update submodules. This option is only respected -when passed before --refresh.

-
-
--unmerged
-
-

If --refresh finds unmerged changes in the index, the default -behavior is to error out. This option makes git update-index - continue anyway.

-
-
--ignore-missing
-
-

Ignores missing files during a --refresh

-
-
--cacheinfo <mode>,<object>,<path>
-
--cacheinfo <mode> <object> <path>
-
-

Directly insert the specified info into the index. For -backward compatibility, you can also give these three -arguments as three separate parameters, but new users are -encouraged to use a single-parameter form.

-
-
--index-info
-
-

Read index information from stdin.

-
-
--chmod=(+|-)x
-
-

Set the execute permissions on the updated files.

-
-
--[no-]assume-unchanged
-
-

When this flag is specified, the object names recorded -for the paths are not updated. Instead, this option -sets/unsets the "assume unchanged" bit for the -paths. When the "assume unchanged" bit is on, the user -promises not to change the file and allows Git to assume -that the working tree file matches what is recorded in -the index. If you want to change the working tree file, -you need to unset the bit to tell Git. This is -sometimes helpful when working with a big project on a -filesystem that has a very slow lstat(2) system call -(e.g. cifs).

-
-

Git will fail (gracefully) in case it needs to modify this file -in the index e.g. when merging in a commit; -thus, in case the assumed-untracked file is changed upstream, -you will need to handle the situation manually.

-
-
-
--really-refresh
-
-

Like --refresh, but checks stat information unconditionally, -without regard to the "assume unchanged" setting.

-
-
--[no-]skip-worktree
-
-

When one of these flags is specified, the object names recorded -for the paths are not updated. Instead, these options -set and unset the "skip-worktree" bit for the paths. See -section "Skip-worktree bit" below for more information.

-
-
--[no-]ignore-skip-worktree-entries
-
-

Do not remove skip-worktree (AKA "index-only") entries even when -the --remove option was specified.

-
-
--[no-]fsmonitor-valid
-
-

When one of these flags is specified, the object names recorded -for the paths are not updated. Instead, these options -set and unset the "fsmonitor valid" bit for the paths. See -section "File System Monitor" below for more information.

-
-
-g
-
--again
-
-

Runs git update-index itself on the paths whose index -entries are different from those of the HEAD commit.

-
-
--unresolve
-
-

Restores the unmerged or needs updating state of a -file during a merge if it was cleared by accident.

-
-
--info-only
-
-

Do not create objects in the object database for all -<file> arguments that follow this flag; just insert -their object IDs into the index.

-
-
--force-remove
-
-

Remove the file from the index even when the working directory -still has such a file. (Implies --remove.)

-
-
--replace
-
-

By default, when a file path exists in the index, -git update-index refuses an attempt to add path/file. -Similarly if a file path/file exists, a file path -cannot be added. With --replace flag, existing entries -that conflict with the entry being added are -automatically removed with warning messages.

-
-
--stdin
-
-

Instead of taking a list of paths from the command line, -read a list of paths from the standard input. Paths are -separated by LF (i.e. one path per line) by default.

-
-
--verbose
-
-

Report what is being added and removed from the index.

-
-
--index-version <n>
-
-

Write the resulting index out in the named on-disk format version. -Supported versions are 2, 3, and 4. The current default version is 2 -or 3, depending on whether extra features are used, such as -git add -N. With --verbose, also report the version the index -file uses before and after this command.

-
-

Version 4 performs a simple pathname compression that reduces index -size by 30%-50% on large repositories, which results in faster load -time. Git supports it since version 1.8.0, released in October 2012, -and support for it was added to libgit2 in 2016 and to JGit in 2020. -Older versions of this manual page called it "relatively young", but -it should be considered mature technology these days.

-
-
-
--show-index-version
-
-

Report the index format version used by the on-disk index file. -See --index-version above.

-
-
-z
-
-

Only meaningful with --stdin or --index-info; paths are -separated with NUL character instead of LF.

-
-
--split-index
-
--no-split-index
-
-

Enable or disable split index mode. If split-index mode is -already enabled and --split-index is given again, all -changes in $GIT_DIR/index are pushed back to the shared index -file.

-
-

These options take effect whatever the value of the core.splitIndex -configuration variable (see git-config[1]). But a warning is -emitted when the change goes against the configured value, as the -configured value will take effect next time the index is read and this -will remove the intended effect of the option.

-
-
-
--untracked-cache
-
--no-untracked-cache
-
-

Enable or disable untracked cache feature. Please use ---test-untracked-cache before enabling it.

-
-

These options take effect whatever the value of the core.untrackedCache -configuration variable (see git-config[1]). But a warning is -emitted when the change goes against the configured value, as the -configured value will take effect next time the index is read and this -will remove the intended effect of the option.

-
-
-
--test-untracked-cache
-
-

Only perform tests on the working directory to make sure -untracked cache can be used. You have to manually enable -untracked cache using --untracked-cache or ---force-untracked-cache or the core.untrackedCache -configuration variable afterwards if you really want to use -it. If a test fails the exit code is 1 and a message -explains what is not working as needed, otherwise the exit -code is 0 and OK is printed.

-
-
--force-untracked-cache
-
-

Same as --untracked-cache. Provided for backwards -compatibility with older versions of Git where ---untracked-cache used to imply --test-untracked-cache but -this option would enable the extension unconditionally.

-
-
--fsmonitor
-
--no-fsmonitor
-
-

Enable or disable files system monitor feature. These options -take effect whatever the value of the core.fsmonitor -configuration variable (see git-config[1]). But a warning -is emitted when the change goes against the configured value, as -the configured value will take effect next time the index is -read and this will remove the intended effect of the option.

-
-
--
-
-

Do not interpret any more arguments as options.

-
-
<file>
-
-

Files to act on. -Note that files beginning with . are discarded. This includes -./file and dir/./file. If you don’t want this, then use -cleaner names. -The same applies to directories ending / and paths with //

-
-
-
-
-
-
-

USING --REFRESH

-
-
-

--refresh does not calculate a new sha1 file or bring the index -up to date for mode/content changes. But what it does do is to -"re-match" the stat information of a file with the index, so that you -can refresh the index for a file that hasn’t been changed but where -the stat entry is out of date.

-
-
-

For example, you’d want to do this after doing a git read-tree, to link -up the stat index details with the proper files.

-
-
-
-
-

USING --CACHEINFO OR --INFO-ONLY

-
-
-

--cacheinfo is used to register a file that is not in the -current working directory. This is useful for minimum-checkout -merging.

-
-
-

To pretend you have a file at path with mode and sha1, say:

-
-
-
-
$ git update-index --add --cacheinfo <mode>,<sha1>,<path>
-
-
-
-

--info-only is used to register files without placing them in the object -database. This is useful for status-only repositories.

-
-
-

Both --cacheinfo and --info-only behave similarly: the index is updated -but the object database isn’t. --cacheinfo is useful when the object is -in the database but the file isn’t available locally. --info-only is -useful when the file is available, but you do not wish to update the -object database.

-
-
-
-
-

USING --INDEX-INFO

-
-
-

--index-info is a more powerful mechanism that lets you feed -multiple entry definitions from the standard input, and designed -specifically for scripts. It can take inputs of three formats:

-
-
-
    -
  1. -

    mode SP type SP sha1 TAB path

    -
    -

    This format is to stuff git ls-tree output into the index.

    -
    -
    2. -
  2. -

    mode SP sha1 SP stage TAB path

    -
    -

    This format is to put higher order stages into the -index file and matches git ls-files --stage output.

    -
    -
    3. -
  3. -

    mode SP sha1 TAB path

    -
    -

    This format is no longer produced by any Git command, but is -and will continue to be supported by update-index --index-info.

    -
    -
    4. -
-
-
-

To place a higher stage entry to the index, the path should -first be removed by feeding a mode=0 entry for the path, and -then feeding necessary input lines in the third format.

-
-
-

For example, starting with this index:

-
-
-
-
$ git ls-files -s
-100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0       frotz
-
-
-
-

you can feed the following input to --index-info:

-
-
-
-
$ git update-index --index-info
-0 0000000000000000000000000000000000000000	frotz
-100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1	frotz
-100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2	frotz
-
-
-
-

The first line of the input feeds 0 as the mode to remove the -path; the SHA-1 does not matter as long as it is well formatted. -Then the second and third line feeds stage 1 and stage 2 entries -for that path. After the above, we would end up with this:

-
-
-
-
$ git ls-files -s
-100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1	frotz
-100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2	frotz
-
-
-
-
-
-

USING “ASSUME UNCHANGED” BIT

-
-
-

Many operations in Git depend on your filesystem to have an -efficient lstat(2) implementation, so that st_mtime -information for working tree files can be cheaply checked to see -if the file contents have changed from the version recorded in -the index file. Unfortunately, some filesystems have -inefficient lstat(2). If your filesystem is one of them, you -can set "assume unchanged" bit to paths you have not changed to -cause Git not to do this check. Note that setting this bit on a -path does not mean Git will check the contents of the file to -see if it has changed — it makes Git to omit any checking and -assume it has not changed. When you make changes to working -tree files, you have to explicitly tell Git about it by dropping -"assume unchanged" bit, either before or after you modify them.

-
-
-

In order to set "assume unchanged" bit, use --assume-unchanged -option. To unset, use --no-assume-unchanged. To see which files -have the "assume unchanged" bit set, use git ls-files -v -(see git-ls-files[1]).

-
-
-

The command looks at core.ignorestat configuration variable. When -this is true, paths updated with git update-index paths... and -paths updated with other Git commands that update both index and -working tree (e.g. git apply --index, git checkout-index -u, -and git read-tree -u) are automatically marked as "assume -unchanged". Note that "assume unchanged" bit is not set if -git update-index --refresh finds the working tree file matches -the index (use git update-index --really-refresh if you want -to mark them as "assume unchanged").

-
-
-

Sometimes users confuse the assume-unchanged bit with the -skip-worktree bit. See the final paragraph in the "Skip-worktree bit" -section below for an explanation of the differences.

-
-
-
-
-

EXAMPLES

-
-
-

To update and refresh only the files already checked out:

-
-
-
-
$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
-
-
-
-
-
On an inefficient filesystem with core.ignorestat set
-
-
-
-
$ git update-index --really-refresh              (1)
-$ git update-index --no-assume-unchanged foo.c   (2)
-$ git diff --name-only                           (3)
-$ edit foo.c
-$ git diff --name-only                           (4)
-M foo.c
-$ git update-index foo.c                         (5)
-$ git diff --name-only                           (6)
-$ edit foo.c
-$ git diff --name-only                           (7)
-$ git update-index --no-assume-unchanged foo.c   (8)
-$ git diff --name-only                           (9)
-M foo.c
-
-
-
-
    -
  1. -

    forces lstat(2) to set "assume unchanged" bits for paths that match index.

    -
    2. -
  2. -

    mark the path to be edited.

    -
    3. -
  3. -

    this does lstat(2) and finds index matches the path.

    -
    4. -
  4. -

    this does lstat(2) and finds index does not match the path.

    -
    5. -
  5. -

    registering the new version to index sets "assume unchanged" bit.

    -
    6. -
  6. -

    and it is assumed unchanged.

    -
    7. -
  7. -

    even after you edit it.

    -
    8. -
  8. -

    you can tell about the change after the fact.

    -
    9. -
  9. -

    now it checks with lstat(2) and finds it has been changed.

    -
    10. -
-
-
-
-
-
-
-
-

SKIP-WORKTREE BIT

-
-
-

Skip-worktree bit can be defined in one (long) sentence: Tell git to -avoid writing the file to the working directory when reasonably -possible, and treat the file as unchanged when it is not -present in the working directory.

-
-
-

Note that not all git commands will pay attention to this bit, and -some only partially support it.

-
-
-

The update-index flags and the read-tree capabilities relating to the -skip-worktree bit predated the introduction of the -git-sparse-checkout[1] command, which provides a much easier -way to configure and handle the skip-worktree bits. If you want to -reduce your working tree to only deal with a subset of the files in -the repository, we strongly encourage the use of -git-sparse-checkout[1] in preference to the low-level -update-index and read-tree primitives.

-
-
-

The primary purpose of the skip-worktree bit is to enable sparse -checkouts, i.e. to have working directories with only a subset of -paths present. When the skip-worktree bit is set, Git commands (such -as switch, pull, merge) will avoid writing these files. -However, these commands will sometimes write these files anyway in -important cases such as conflicts during a merge or rebase. Git -commands will also avoid treating the lack of such files as an -intentional deletion; for example git add -u will not stage a -deletion for these files and git commit -a will not make a commit -deleting them either.

-
-
-

Although this bit looks similar to assume-unchanged bit, its goal is -different. The assume-unchanged bit is for leaving the file in the -working tree but having Git omit checking it for changes and presuming -that the file has not been changed (though if it can determine without -stat’ing the file that it has changed, it is free to record the -changes). skip-worktree tells Git to ignore the absence of the file, -avoid updating it when possible with commands that normally update -much of the working directory (e.g. checkout, switch, pull, -etc.), and not have its absence be recorded in commits. Note that in -sparse checkouts (setup by git sparse-checkout or by configuring -core.sparseCheckout to true), if a file is marked as skip-worktree in -the index but is found in the working tree, Git will clear the -skip-worktree bit for that file.

-
-
-
-
-

SPLIT INDEX

-
-
-

This mode is designed for repositories with very large indexes, and -aims at reducing the time it takes to repeatedly write these indexes.

-
-
-

In this mode, the index is split into two files, $GIT_DIR/index and -$GIT_DIR/sharedindex.<SHA-1>. Changes are accumulated in -$GIT_DIR/index, the split index, while the shared index file contains -all index entries and stays unchanged.

-
-
-

All changes in the split index are pushed back to the shared index -file when the number of entries in the split index reaches a level -specified by the splitIndex.maxPercentChange config variable (see -git-config[1]).

-
-
-

Each time a new shared index file is created, the old shared index -files are deleted if their modification time is older than what is -specified by the splitIndex.sharedIndexExpire config variable (see -git-config[1]).

-
-
-

To avoid deleting a shared index file that is still used, its -modification time is updated to the current time every time a new split -index based on the shared index file is either created or read from.

-
-
-
-
-

UNTRACKED CACHE

-
-
-

This cache is meant to speed up commands that involve determining -untracked files such as git status.

-
-
-

This feature works by recording the mtime of the working tree -directories and then omitting reading directories and stat calls -against files in those directories whose mtime hasn’t changed. For -this to work the underlying operating system and file system must -change the st_mtime field of directories if files in the directory -are added, modified or deleted.

-
-
-

You can test whether the filesystem supports that with the ---test-untracked-cache option. The --untracked-cache option used -to implicitly perform that test in older versions of Git, but that’s -no longer the case.

-
-
-

If you want to enable (or disable) this feature, it is easier to use -the core.untrackedCache configuration variable (see -git-config[1]) than using the --untracked-cache option to -git update-index in each repository, especially if you want to do so -across all repositories you use, because you can set the configuration -variable to true (or false) in your $HOME/.gitconfig just once -and have it affect all repositories you touch.

-
-
-

When the core.untrackedCache configuration variable is changed, the -untracked cache is added to or removed from the index the next time a -command reads the index; while when --[no-|force-]untracked-cache -are used, the untracked cache is immediately added to or removed from -the index.

-
-
-

Before 2.17, the untracked cache had a bug where replacing a directory -with a symlink to another directory could cause it to incorrectly show -files tracked by git as untracked. See the "status: add a failing test -showing a core.untrackedCache bug" commit to git.git. A workaround for -that is (and this might work for other undiscovered bugs in the -future):

-
-
-
-
$ git -c core.untrackedCache=false status
-
-
-
-

This bug has also been shown to affect non-symlink cases of replacing -a directory with a file when it comes to the internal structures of -the untracked cache, but no case has been reported where this resulted in -wrong "git status" output.

-
-
-

There are also cases where existing indexes written by git versions -before 2.17 will reference directories that don’t exist anymore, -potentially causing many "could not open directory" warnings to be -printed on "git status". These are new warnings for existing issues -that were previously silently discarded.

-
-
-

As with the bug described above the solution is to one-off do a "git -status" run with core.untrackedCache=false to flush out the leftover -bad data.

-
-
-
-
-

FILE SYSTEM MONITOR

-
-
-

This feature is intended to speed up git operations for repos that have -large working directories.

-
-
-

It enables git to work together with a file system monitor (see -git-fsmonitor--daemon[1] -and the -"fsmonitor-watchman" section of githooks[5]) that can -inform it as to what files have been modified. This enables git to avoid -having to lstat() every file to find modified files.

-
-
-

When used in conjunction with the untracked cache, it can further improve -performance by avoiding the cost of scanning the entire working directory -looking for new files.

-
-
-

If you want to enable (or disable) this feature, it is easier to use -the core.fsmonitor configuration variable (see -git-config[1]) than using the --fsmonitor option to git -update-index in each repository, especially if you want to do so -across all repositories you use, because you can set the configuration -variable in your $HOME/.gitconfig just once and have it affect all -repositories you touch.

-
-
-

When the core.fsmonitor configuration variable is changed, the -file system monitor is added to or removed from the index the next time -a command reads the index. When --[no-]fsmonitor are used, the file -system monitor is immediately added to or removed from the index.

-
-
-
-
-

CONFIGURATION

-
-
-

The command honors core.filemode configuration variable. If -your repository is on a filesystem whose executable bits are -unreliable, this should be set to false (see git-config[1]). -This causes the command to ignore differences in file modes recorded -in the index and the file mode on the filesystem if they differ only on -executable bit. On such an unfortunate filesystem, you may -need to use git update-index --chmod=.

-
-
-

Quite similarly, if core.symlinks configuration variable is set -to false (see git-config[1]), symbolic links are checked out -as plain files, and this command does not modify a recorded file mode -from symbolic link to regular file.

-
-
-

The command looks at core.ignorestat configuration variable. See -Using "assume unchanged" bit section above.

-
-
-

The command also looks at core.trustctime configuration variable. -It can be useful when the inode change time is regularly modified by -something outside Git (file system crawlers and backup systems use -ctime for marking files processed) (see git-config[1]).

-
-
-

The untracked cache extension can be enabled by the -core.untrackedCache configuration variable (see -git-config[1]).

-
-
-
-
-

NOTES

-
-
-

Users often try to use the assume-unchanged and skip-worktree bits -to tell Git to ignore changes to files that are tracked. This does not -work as expected, since Git may still check working tree files against -the index when performing certain operations. In general, Git does not -provide a way to ignore changes to tracked files, so alternate solutions -are recommended.

-
-
-

For example, if the file you want to change is some sort of config file, -the repository can include a sample config file that can then be copied -into the ignored name and modified. The repository can even include a -script to treat the sample file as a template, modifying and copying it -automatically.

-
-
-
-
-

SEE ALSO

-
-
-

git-config[1], -git-add[1], -git-ls-files[1]

-
-
-
-
-

GIT

-
-
-

Part of the git[1] suite

-
-
-
\ No newline at end of file diff --git a/external/docs/content/docs/git.html b/external/docs/content/docs/git.html index ac63cfa7a0..0e71107030 100644 --- a/external/docs/content/docs/git.html +++ b/external/docs/content/docs/git.html @@ -313,16 +313,319 @@

Main porcelain commands

- +
+
+
git-add[1]
+
+

Add file contents to the index

+
+
git-am[1]
+
+

Apply a series of patches from a mailbox

+
+
git-archive[1]
+
+

Create an archive of files from a named tree

+
+
git-bisect[1]
+
+

Use binary search to find the commit that introduced a bug

+
+
git-branch[1]
+
+

List, create, or delete branches

+
+
git-bundle[1]
+
+

Move objects and refs by archive

+
+
git-checkout[1]
+
+

Switch branches or restore working tree files

+
+
git-cherry-pick[1]
+
+

Apply the changes introduced by some existing commits

+
+
git-citool[1]
+
+

Graphical alternative to git-commit

+
+
git-clean[1]
+
+

Remove untracked files from the working tree

+
+
git-clone[1]
+
+

Clone a repository into a new directory

+
+
git-commit[1]
+
+

Record changes to the repository

+
+
git-describe[1]
+
+

Give an object a human readable name based on an available ref

+
+
git-diff[1]
+
+

Show changes between commits, commit and working tree, etc

+
+
git-fetch[1]
+
+

Download objects and refs from another repository

+
+
git-format-patch[1]
+
+

Prepare patches for e-mail submission

+
+
git-gc[1]
+
+

Cleanup unnecessary files and optimize the local repository

+
+
git-grep[1]
+
+

Print lines matching a pattern

+
+
git-gui[1]
+
+

A portable graphical interface to Git

+
+
git-init[1]
+
+

Create an empty Git repository or reinitialize an existing one

+
+
git-log[1]
+
+

Show commit logs

+
+
git-maintenance[1]
+
+

Run tasks to optimize Git repository data

+
+
git-merge[1]
+
+

Join two or more development histories together

+
+
git-mv[1]
+
+

Move or rename a file, a directory, or a symlink

+
+
git-notes[1]
+
+

Add or inspect object notes

+
+
git-pull[1]
+
+

Fetch from and integrate with another repository or a local branch

+
+
git-push[1]
+
+

Update remote refs along with associated objects

+
+
git-range-diff[1]
+
+

Compare two commit ranges (e.g. two versions of a branch)

+
+
git-rebase[1]
+
+

Reapply commits on top of another base tip

+
+
git-reset[1]
+
+

Reset current HEAD to the specified state

+
+
git-restore[1]
+
+

Restore working tree files

+
+
git-revert[1]
+
+

Revert some existing commits

+
+
git-rm[1]
+
+

Remove files from the working tree and from the index

+
+
git-shortlog[1]
+
+

Summarize git log output

+
+
git-show[1]
+
+

Show various types of objects

+
+
git-sparse-checkout[1]
+
+

Reduce your working tree to a subset of tracked files

+
+
git-stash[1]
+
+

Stash the changes in a dirty working directory away

+
+
git-status[1]
+
+

Show the working tree status

+
+
git-submodule[1]
+
+

Initialize, update or inspect submodules

+
+
git-switch[1]
+
+

Switch branches

+
+
git-tag[1]
+
+

Create, list, delete or verify a tag object signed with GPG

+
+
git-worktree[1]
+
+

Manage multiple working trees

+
+
gitk[1]
+
+

The Git repository browser

+
+
scalar[1]
+
+

A tool for managing large Git repositories

+
+
+

Ancillary Commands

Manipulators:

+
+
+
git-config[1]
+
+

Get and set repository or global options

+
+
git-fast-export[1]
+
+

Git data exporter

+
+
git-fast-import[1]
+
+

Backend for fast Git data importers

+
+
git-filter-branch[1]
+
+

Rewrite branches

+
+
git-mergetool[1]
+
+

Run merge conflict resolution tools to resolve merge conflicts

+
+
git-pack-refs[1]
+
+

Pack heads and tags for efficient repository access

+
+
git-prune[1]
+
+

Prune all unreachable objects from the object database

+
+
git-reflog[1]
+
+

Manage reflog information

+
+
git-refs[1]
+
+

Low-level access to refs

+
+
git-remote[1]
+
+

Manage set of tracked repositories

+
+
git-repack[1]
+
+

Pack unpacked objects in a repository

+
+
git-replace[1]
+
+

Create, list, delete refs to replace objects

+
+
+

Interrogators:

+
+
+
git-annotate[1]
+
+

Annotate file lines with commit information

+
+
git-blame[1]
+
+

Show what revision and author last modified each line of a file

+
+
git-bugreport[1]
+
+

Collect information for user to file a bug report

+
+
git-count-objects[1]
+
+

Count unpacked number of objects and their disk consumption

+
+
git-diagnose[1]
+
+

Generate a zip archive of diagnostic information

+
+
git-difftool[1]
+
+

Show changes using common diff tools

+
+
git-fsck[1]
+
+

Verifies the connectivity and validity of the objects in the database

+
+
git-help[1]
+
+

Display help information about Git

+
+
git-instaweb[1]
+
+

Instantly browse your working repository in gitweb

+
+
git-merge-tree[1]
+
+

Perform merge without touching index or working tree

+
+
git-rerere[1]
+
+

Reuse recorded resolution of conflicted merges

+
+
git-show-branch[1]
+
+

Show branches and their commits

+
+
git-verify-commit[1]
+
+

Check the GPG signature of commits

+
+
git-verify-tag[1]
+
+

Check the GPG signature of tags

+
+
git-version[1]
+
+

Display version information about Git

+
+
git-whatchanged[1]
+
+

Show logs with differences each commit introduces

+
+
gitweb[1]
+
+

Git web interface (web frontend to Git repositories)

+
+
+

Interacting with Others

@@ -330,6 +633,50 @@

+
+
git-archimport[1]
+
+

Import a GNU Arch repository into Git

+
+
git-cvsexportcommit[1]
+
+

Export a single commit to a CVS checkout

+
+
git-cvsimport[1]
+
+

Salvage your data out of another SCM people love to hate

+
+
git-cvsserver[1]
+
+

A CVS server emulator for Git

+
+
git-imap-send[1]
+
+

Send a collection of patches from stdin to an IMAP folder

+
+
git-p4[1]
+
+

Import from and submit to Perforce repositories

+
+
git-quiltimport[1]
+
+

Applies a quilt patchset onto the current branch

+
+
git-request-pull[1]
+
+

Generates a summary of pending changes

+
+
git-send-email[1]
+
+

Send a collection of patches as emails

+
+
git-svn[1]
+
+

Bidirectional operation between a Subversion repository and Git

+
+
+

Reset, restore and revert

@@ -390,10 +737,181 @@

Manipulation commands

- +
+
+
git-apply[1]
+
+

Apply a patch to files and/or to the index

+
+
git-checkout-index[1]
+
+

Copy files from the index to the working tree

+
+
git-commit-graph[1]
+
+

Write and verify Git commit-graph files

+
+
git-commit-tree[1]
+
+

Create a new commit object

+
+
git-hash-object[1]
+
+

Compute object ID and optionally create an object from a file

+
+
git-index-pack[1]
+
+

Build pack index file for an existing packed archive

+
+
git-merge-file[1]
+
+

Run a three-way file merge

+
+
git-merge-index[1]
+
+

Run a merge for files needing merging

+
+
git-mktag[1]
+
+

Creates a tag object with extra validation

+
+
git-mktree[1]
+
+

Build a tree-object from ls-tree formatted text

+
+
git-multi-pack-index[1]
+
+

Write and verify multi-pack-indexes

+
+
git-pack-objects[1]
+
+

Create a packed archive of objects

+
+
git-prune-packed[1]
+
+

Remove extra objects that are already in pack files

+
+
git-read-tree[1]
+
+

Reads tree information into the index

+
+
git-replay[1]
+
+

EXPERIMENTAL: Replay commits on a new base, works with bare repos too

+
+
git-symbolic-ref[1]
+
+

Read, modify and delete symbolic refs

+
+
git-unpack-objects[1]
+
+

Unpack objects from a packed archive

+
+
git-update-index[1]
+
+

Register file contents in the working tree to the index

+
+
git-update-ref[1]
+
+

Update the object name stored in a ref safely

+
+
git-write-tree[1]
+
+

Create a tree object from the current index

+
+
+

Interrogation commands

+
+
+
git-cat-file[1]
+
+

Provide contents or details of repository objects

+
+
git-cherry[1]
+
+

Find commits yet to be applied to upstream

+
+
git-diff-files[1]
+
+

Compares files in the working tree and the index

+
+
git-diff-index[1]
+
+

Compare a tree to the working tree or index

+
+
git-diff-tree[1]
+
+

Compares the content and mode of blobs found via two tree objects

+
+
git-for-each-ref[1]
+
+

Output information on each ref

+
+
git-for-each-repo[1]
+
+

Run a Git command on a list of repositories

+
+
git-get-tar-commit-id[1]
+
+

Extract commit ID from an archive created using git-archive

+
+
git-ls-files[1]
+
+

Show information about files in the index and the working tree

+
+
git-ls-remote[1]
+
+

List references in a remote repository

+
+
git-ls-tree[1]
+
+

List the contents of a tree object

+
+
git-merge-base[1]
+
+

Find as good common ancestors as possible for a merge

+
+
git-name-rev[1]
+
+

Find symbolic names for given revs

+
+
git-pack-redundant[1]
+
+

Find redundant pack files

+
+
git-rev-list[1]
+
+

Lists commit objects in reverse chronological order

+
+
git-rev-parse[1]
+
+

Pick out and massage parameters

+
+
git-show-index[1]
+
+

Show packed archive index

+
+
git-show-ref[1]
+
+

List references in a local repository

+
+
git-unpack-file[1]
+
+

Creates a temporary file with a blob’s contents

+
+
git-var[1]
+
+

Show a Git logical variable

+
+
git-verify-pack[1]
+
+

Validate packed Git archive files

+
+
+

In general, the interrogate commands do not touch the files in the working tree.

@@ -401,10 +919,62 @@

Syncing repositories

+
+
+
git-daemon[1]
+
+

A really simple server for Git repositories

+
+
git-fetch-pack[1]
+
+

Receive missing objects from another repository

+
+
git-http-backend[1]
+
+

Server side implementation of Git over HTTP

+
+
git-send-pack[1]
+
+

Push objects over Git protocol to another repository

+
+
git-update-server-info[1]
+
+

Update auxiliary info file to help dumb servers

+
+
+

The following are helper commands used by the above; end users typically do not use them directly.

+
+
+
git-http-fetch[1]
+
+

Download from a remote Git repository via HTTP

+
+
git-http-push[1]
+
+

Push objects over HTTP/DAV to another repository

+
+
git-receive-pack[1]
+
+

Receive what is pushed into the repository

+
+
git-shell[1]
+
+

Restricted login shell for Git-only SSH access

+
+
git-upload-archive[1]
+
+

Send archive back to git-archive

+
+
git-upload-pack[1]
+
+

Send objects packed back to git-fetch-pack

+
+
+

Internal helper commands

@@ -412,6 +982,82 @@

+
+
git-check-attr[1]
+
+

Display gitattributes information

+
+
git-check-ignore[1]
+
+

Debug gitignore / exclude files

+
+
git-check-mailmap[1]
+
+

Show canonical names and email addresses of contacts

+
+
git-check-ref-format[1]
+
+

Ensures that a reference name is well formed

+
+
git-column[1]
+
+

Display data in columns

+
+
git-credential[1]
+
+

Retrieve and store user credentials

+
+
git-credential-cache[1]
+
+

Helper to temporarily store passwords in memory

+
+
git-credential-store[1]
+
+

Helper to store credentials on disk

+
+
git-fmt-merge-msg[1]
+
+

Produce a merge commit message

+
+
git-hook[1]
+
+

Run git hooks

+
+
git-interpret-trailers[1]
+
+

Add or parse structured information in commit messages

+
+
git-mailinfo[1]
+
+

Extracts patch and authorship from a single e-mail message

+
+
git-mailsplit[1]
+
+

Simple UNIX mbox splitter program

+
+
git-merge-one-file[1]
+
+

The standard helper program to use with git-merge-index

+
+
git-patch-id[1]
+
+

Compute unique ID for a patch

+
+
git-sh-i18n[1]
+
+

Git’s i18n setup code for shell scripts

+
+
git-sh-setup[1]
+
+

Common Git shell script setup code

+
+
git-stripspace[1]
+
+

Remove unnecessary whitespace

+
+
+

@@ -421,6 +1067,62 @@

Guides

The following documentation pages are guides about Git concepts.

+
+
+
gitcore-tutorial[7]
+
+

A Git core tutorial for developers

+
+
gitcredentials[7]
+
+

Providing usernames and passwords to Git

+
+
gitcvs-migration[7]
+
+

Git for CVS users

+
+
gitdiffcore[7]
+
+

Tweaking diff output

+
+
giteveryday[7]
+
+

A useful minimum set of commands for Everyday Git

+
+
gitfaq[7]
+
+

Frequently asked questions about using Git

+
+
gitglossary[7]
+
+

A Git Glossary

+
+
gitnamespaces[7]
+
+

Git namespaces

+
+
gitremote-helpers[7]
+
+

Helper programs to interact with remote repositories

+
+
gitsubmodules[7]
+
+

Mounting one repository inside another

+
+
gittutorial[7]
+
+

A tutorial introduction to Git

+
+
gittutorial-2[7]
+
+

A tutorial introduction to Git: part two

+
+
gitworkflows[7]
+
+

An overview of recommended workflows with Git

+
+
+
@@ -431,6 +1133,42 @@

}}'>git-help[1] for more details on the criteria.

+
+
+
gitattributes[5]
+
+

Defining attributes per path

+
+
gitcli[7]
+
+

Git command-line interface and conventions

+
+
githooks[5]
+
+

Hooks used by Git

+
+
gitignore[5]
+
+

Specifies intentionally untracked files to ignore

+
+
gitmailmap[5]
+
+

Map author/committer names and/or E-Mail addresses

+
+
gitmodules[5]
+
+

Defining submodule properties

+
+
gitrepository-layout[5]
+
+

Git Repository Layout

+
+
gitrevisions[7]
+
+

Specifying revisions and ranges for Git

+
+
+
@@ -441,6 +1179,54 @@

}}'>git-help[1].

+
+
+
gitformat-bundle[5]
+
+

The bundle file format

+
+
gitformat-chunk[5]
+
+

Chunk-based file formats

+
+
gitformat-commit-graph[5]
+
+

Git commit-graph format

+
+
gitformat-index[5]
+
+

Git index format

+
+
gitformat-pack[5]
+
+

Git pack format

+
+
gitformat-signature[5]
+
+

Git cryptographic signature formats

+
+
gitprotocol-capabilities[5]
+
+

Protocol v0 and v1 capabilities

+
+
gitprotocol-common[5]
+
+

Things common to various protocols

+
+
gitprotocol-http[5]
+
+

Git HTTP-based protocols

+
+
gitprotocol-pack[5]
+
+

How packs are transferred over-the-wire

+
+
gitprotocol-v2[5]
+
+

Git Wire Protocol, Version 2

+
+
+
diff --git a/external/docs/content/docs/git/2.48.0.html b/external/docs/content/docs/git/2.48.0.html index eb2c2c5297..08f53e488a 100644 --- a/external/docs/content/docs/git/2.48.0.html +++ b/external/docs/content/docs/git/2.48.0.html @@ -313,16 +313,319 @@

Main porcelain commands

- +
+
+
git-add[1]
+
+

Add file contents to the index

+
+
git-am[1]
+
+

Apply a series of patches from a mailbox

+
+
git-archive[1]
+
+

Create an archive of files from a named tree

+
+
git-bisect[1]
+
+

Use binary search to find the commit that introduced a bug

+
+
git-branch[1]
+
+

List, create, or delete branches

+
+
git-bundle[1]
+
+

Move objects and refs by archive

+
+
git-checkout[1]
+
+

Switch branches or restore working tree files

+
+
git-cherry-pick[1]
+
+

Apply the changes introduced by some existing commits

+
+
git-citool[1]
+
+

Graphical alternative to git-commit

+
+
git-clean[1]
+
+

Remove untracked files from the working tree

+
+
git-clone[1]
+
+

Clone a repository into a new directory

+
+
git-commit[1]
+
+

Record changes to the repository

+
+
git-describe[1]
+
+

Give an object a human readable name based on an available ref

+
+
git-diff[1]
+
+

Show changes between commits, commit and working tree, etc

+
+
git-fetch[1]
+
+

Download objects and refs from another repository

+
+
git-format-patch[1]
+
+

Prepare patches for e-mail submission

+
+
git-gc[1]
+
+

Cleanup unnecessary files and optimize the local repository

+
+
git-grep[1]
+
+

Print lines matching a pattern

+
+
git-gui[1]
+
+

A portable graphical interface to Git

+
+
git-init[1]
+
+

Create an empty Git repository or reinitialize an existing one

+
+
git-log[1]
+
+

Show commit logs

+
+
git-maintenance[1]
+
+

Run tasks to optimize Git repository data

+
+
git-merge[1]
+
+

Join two or more development histories together

+
+
git-mv[1]
+
+

Move or rename a file, a directory, or a symlink

+
+
git-notes[1]
+
+

Add or inspect object notes

+
+
git-pull[1]
+
+

Fetch from and integrate with another repository or a local branch

+
+
git-push[1]
+
+

Update remote refs along with associated objects

+
+
git-range-diff[1]
+
+

Compare two commit ranges (e.g. two versions of a branch)

+
+
git-rebase[1]
+
+

Reapply commits on top of another base tip

+
+
git-reset[1]
+
+

Reset current HEAD to the specified state

+
+
git-restore[1]
+
+

Restore working tree files

+
+
git-revert[1]
+
+

Revert some existing commits

+
+
git-rm[1]
+
+

Remove files from the working tree and from the index

+
+
git-shortlog[1]
+
+

Summarize git log output

+
+
git-show[1]
+
+

Show various types of objects

+
+
git-sparse-checkout[1]
+
+

Reduce your working tree to a subset of tracked files

+
+
git-stash[1]
+
+

Stash the changes in a dirty working directory away

+
+
git-status[1]
+
+

Show the working tree status

+
+
git-submodule[1]
+
+

Initialize, update or inspect submodules

+
+
git-switch[1]
+
+

Switch branches

+
+
git-tag[1]
+
+

Create, list, delete or verify a tag object signed with GPG

+
+
git-worktree[1]
+
+

Manage multiple working trees

+
+
gitk[1]
+
+

The Git repository browser

+
+
scalar[1]
+
+

A tool for managing large Git repositories

+
+
+

Ancillary Commands

Manipulators:

+
+
+
git-config[1]
+
+

Get and set repository or global options

+
+
git-fast-export[1]
+
+

Git data exporter

+
+
git-fast-import[1]
+
+

Backend for fast Git data importers

+
+
git-filter-branch[1]
+
+

Rewrite branches

+
+
git-mergetool[1]
+
+

Run merge conflict resolution tools to resolve merge conflicts

+
+
git-pack-refs[1]
+
+

Pack heads and tags for efficient repository access

+
+
git-prune[1]
+
+

Prune all unreachable objects from the object database

+
+
git-reflog[1]
+
+

Manage reflog information

+
+
git-refs[1]
+
+

Low-level access to refs

+
+
git-remote[1]
+
+

Manage set of tracked repositories

+
+
git-repack[1]
+
+

Pack unpacked objects in a repository

+
+
git-replace[1]
+
+

Create, list, delete refs to replace objects

+
+
+

Interrogators:

+
+
+
git-annotate[1]
+
+

Annotate file lines with commit information

+
+
git-blame[1]
+
+

Show what revision and author last modified each line of a file

+
+
git-bugreport[1]
+
+

Collect information for user to file a bug report

+
+
git-count-objects[1]
+
+

Count unpacked number of objects and their disk consumption

+
+
git-diagnose[1]
+
+

Generate a zip archive of diagnostic information

+
+
git-difftool[1]
+
+

Show changes using common diff tools

+
+
git-fsck[1]
+
+

Verifies the connectivity and validity of the objects in the database

+
+
git-help[1]
+
+

Display help information about Git

+
+
git-instaweb[1]
+
+

Instantly browse your working repository in gitweb

+
+
git-merge-tree[1]
+
+

Perform merge without touching index or working tree

+
+
git-rerere[1]
+
+

Reuse recorded resolution of conflicted merges

+
+
git-show-branch[1]
+
+

Show branches and their commits

+
+
git-verify-commit[1]
+
+

Check the GPG signature of commits

+
+
git-verify-tag[1]
+
+

Check the GPG signature of tags

+
+
git-version[1]
+
+

Display version information about Git

+
+
git-whatchanged[1]
+
+

Show logs with differences each commit introduces

+
+
gitweb[1]
+
+

Git web interface (web frontend to Git repositories)

+
+
+

Interacting with Others

@@ -330,6 +633,50 @@

+
+
git-archimport[1]
+
+

Import a GNU Arch repository into Git

+
+
git-cvsexportcommit[1]
+
+

Export a single commit to a CVS checkout

+
+
git-cvsimport[1]
+
+

Salvage your data out of another SCM people love to hate

+
+
git-cvsserver[1]
+
+

A CVS server emulator for Git

+
+
git-imap-send[1]
+
+

Send a collection of patches from stdin to an IMAP folder

+
+
git-p4[1]
+
+

Import from and submit to Perforce repositories

+
+
git-quiltimport[1]
+
+

Applies a quilt patchset onto the current branch

+
+
git-request-pull[1]
+
+

Generates a summary of pending changes

+
+
git-send-email[1]
+
+

Send a collection of patches as emails

+
+
git-svn[1]
+
+

Bidirectional operation between a Subversion repository and Git

+
+
+

Reset, restore and revert

@@ -390,10 +737,181 @@

Manipulation commands

- +
+
+
git-apply[1]
+
+

Apply a patch to files and/or to the index

+
+
git-checkout-index[1]
+
+

Copy files from the index to the working tree

+
+
git-commit-graph[1]
+
+

Write and verify Git commit-graph files

+
+
git-commit-tree[1]
+
+

Create a new commit object

+
+
git-hash-object[1]
+
+

Compute object ID and optionally create an object from a file

+
+
git-index-pack[1]
+
+

Build pack index file for an existing packed archive

+
+
git-merge-file[1]
+
+

Run a three-way file merge

+
+
git-merge-index[1]
+
+

Run a merge for files needing merging

+
+
git-mktag[1]
+
+

Creates a tag object with extra validation

+
+
git-mktree[1]
+
+

Build a tree-object from ls-tree formatted text

+
+
git-multi-pack-index[1]
+
+

Write and verify multi-pack-indexes

+
+
git-pack-objects[1]
+
+

Create a packed archive of objects

+
+
git-prune-packed[1]
+
+

Remove extra objects that are already in pack files

+
+
git-read-tree[1]
+
+

Reads tree information into the index

+
+
git-replay[1]
+
+

EXPERIMENTAL: Replay commits on a new base, works with bare repos too

+
+
git-symbolic-ref[1]
+
+

Read, modify and delete symbolic refs

+
+
git-unpack-objects[1]
+
+

Unpack objects from a packed archive

+
+
git-update-index[1]
+
+

Register file contents in the working tree to the index

+
+
git-update-ref[1]
+
+

Update the object name stored in a ref safely

+
+
git-write-tree[1]
+
+

Create a tree object from the current index

+
+
+

Interrogation commands

+
+
+
git-cat-file[1]
+
+

Provide contents or details of repository objects

+
+
git-cherry[1]
+
+

Find commits yet to be applied to upstream

+
+
git-diff-files[1]
+
+

Compares files in the working tree and the index

+
+
git-diff-index[1]
+
+

Compare a tree to the working tree or index

+
+
git-diff-tree[1]
+
+

Compares the content and mode of blobs found via two tree objects

+
+
git-for-each-ref[1]
+
+

Output information on each ref

+
+
git-for-each-repo[1]
+
+

Run a Git command on a list of repositories

+
+
git-get-tar-commit-id[1]
+
+

Extract commit ID from an archive created using git-archive

+
+
git-ls-files[1]
+
+

Show information about files in the index and the working tree

+
+
git-ls-remote[1]
+
+

List references in a remote repository

+
+
git-ls-tree[1]
+
+

List the contents of a tree object

+
+
git-merge-base[1]
+
+

Find as good common ancestors as possible for a merge

+
+
git-name-rev[1]
+
+

Find symbolic names for given revs

+
+
git-pack-redundant[1]
+
+

Find redundant pack files

+
+
git-rev-list[1]
+
+

Lists commit objects in reverse chronological order

+
+
git-rev-parse[1]
+
+

Pick out and massage parameters

+
+
git-show-index[1]
+
+

Show packed archive index

+
+
git-show-ref[1]
+
+

List references in a local repository

+
+
git-unpack-file[1]
+
+

Creates a temporary file with a blob’s contents

+
+
git-var[1]
+
+

Show a Git logical variable

+
+
git-verify-pack[1]
+
+

Validate packed Git archive files

+
+
+

In general, the interrogate commands do not touch the files in the working tree.

@@ -401,10 +919,62 @@

Syncing repositories

+
+
+
git-daemon[1]
+
+

A really simple server for Git repositories

+
+
git-fetch-pack[1]
+
+

Receive missing objects from another repository

+
+
git-http-backend[1]
+
+

Server side implementation of Git over HTTP

+
+
git-send-pack[1]
+
+

Push objects over Git protocol to another repository

+
+
git-update-server-info[1]
+
+

Update auxiliary info file to help dumb servers

+
+
+

The following are helper commands used by the above; end users typically do not use them directly.

+
+
+
git-http-fetch[1]
+
+

Download from a remote Git repository via HTTP

+
+
git-http-push[1]
+
+

Push objects over HTTP/DAV to another repository

+
+
git-receive-pack[1]
+
+

Receive what is pushed into the repository

+
+
git-shell[1]
+
+

Restricted login shell for Git-only SSH access

+
+
git-upload-archive[1]
+
+

Send archive back to git-archive

+
+
git-upload-pack[1]
+
+

Send objects packed back to git-fetch-pack

+
+
+

Internal helper commands

@@ -412,6 +982,82 @@

+
+
git-check-attr[1]
+
+

Display gitattributes information

+
+
git-check-ignore[1]
+
+

Debug gitignore / exclude files

+
+
git-check-mailmap[1]
+
+

Show canonical names and email addresses of contacts

+
+
git-check-ref-format[1]
+
+

Ensures that a reference name is well formed

+
+
git-column[1]
+
+

Display data in columns

+
+
git-credential[1]
+
+

Retrieve and store user credentials

+
+
git-credential-cache[1]
+
+

Helper to temporarily store passwords in memory

+
+
git-credential-store[1]
+
+

Helper to store credentials on disk

+
+
git-fmt-merge-msg[1]
+
+

Produce a merge commit message

+
+
git-hook[1]
+
+

Run git hooks

+
+
git-interpret-trailers[1]
+
+

Add or parse structured information in commit messages

+
+
git-mailinfo[1]
+
+

Extracts patch and authorship from a single e-mail message

+
+
git-mailsplit[1]
+
+

Simple UNIX mbox splitter program

+
+
git-merge-one-file[1]
+
+

The standard helper program to use with git-merge-index

+
+
git-patch-id[1]
+
+

Compute unique ID for a patch

+
+
git-sh-i18n[1]
+
+

Git’s i18n setup code for shell scripts

+
+
git-sh-setup[1]
+
+

Common Git shell script setup code

+
+
git-stripspace[1]
+
+

Remove unnecessary whitespace

+
+
+

@@ -421,6 +1067,62 @@

Guides

The following documentation pages are guides about Git concepts.

+
+
+
gitcore-tutorial[7]
+
+

A Git core tutorial for developers

+
+
gitcredentials[7]
+
+

Providing usernames and passwords to Git

+
+
gitcvs-migration[7]
+
+

Git for CVS users

+
+
gitdiffcore[7]
+
+

Tweaking diff output

+
+
giteveryday[7]
+
+

A useful minimum set of commands for Everyday Git

+
+
gitfaq[7]
+
+

Frequently asked questions about using Git

+
+
gitglossary[7]
+
+

A Git Glossary

+
+
gitnamespaces[7]
+
+

Git namespaces

+
+
gitremote-helpers[7]
+
+

Helper programs to interact with remote repositories

+
+
gitsubmodules[7]
+
+

Mounting one repository inside another

+
+
gittutorial[7]
+
+

A tutorial introduction to Git

+
+
gittutorial-2[7]
+
+

A tutorial introduction to Git: part two

+
+
gitworkflows[7]
+
+

An overview of recommended workflows with Git

+
+
+
@@ -431,6 +1133,42 @@

}}'>git-help[1] for more details on the criteria.

+
+
+
gitattributes[5]
+
+

Defining attributes per path

+
+
gitcli[7]
+
+

Git command-line interface and conventions

+
+
githooks[5]
+
+

Hooks used by Git

+
+
gitignore[5]
+
+

Specifies intentionally untracked files to ignore

+
+
gitmailmap[5]
+
+

Map author/committer names and/or E-Mail addresses

+
+
gitmodules[5]
+
+

Defining submodule properties

+
+
gitrepository-layout[5]
+
+

Git Repository Layout

+
+
gitrevisions[7]
+
+

Specifying revisions and ranges for Git

+
+
+
@@ -441,6 +1179,54 @@

}}'>git-help[1].

+
+
+
gitformat-bundle[5]
+
+

The bundle file format

+
+
gitformat-chunk[5]
+
+

Chunk-based file formats

+
+
gitformat-commit-graph[5]
+
+

Git commit-graph format

+
+
gitformat-index[5]
+
+

Git index format

+
+
gitformat-pack[5]
+
+

Git pack format

+
+
gitformat-signature[5]
+
+

Git cryptographic signature formats

+
+
gitprotocol-capabilities[5]
+
+

Protocol v0 and v1 capabilities

+
+
gitprotocol-common[5]
+
+

Things common to various protocols

+
+
gitprotocol-http[5]
+
+

Git HTTP-based protocols

+
+
gitprotocol-pack[5]
+
+

How packs are transferred over-the-wire

+
+
gitprotocol-v2[5]
+
+

Git Wire Protocol, Version 2

+
+
+
diff --git a/external/docs/data/docs.yml b/external/docs/data/docs.yml index 163ee8b1d3..a43078e588 100644 --- a/external/docs/data/docs.yml +++ b/external/docs/data/docs.yml @@ -49166,7 +49166,7 @@ pages: 2.46.2: fb6372d5c849d4357294e5f39d5af70e4ada408e 2.47.0: fc934ece0c6da2a4b94fc765f86ba70388d663f9 2.47.1: fc934ece0c6da2a4b94fc765f86ba70388d663f9 - 2.48.0: 7360d343bd22b796aa23b92375da5ec16d6841e6 + 2.48.0: 73ae4b8924e2c768a0a6ba30c01b634b977ea780 2.40.4: 485657d5f0186076956f05ba525396519553c0fa 2.41.3: da646f5f0aee1da0a12e0087b540f162523b5d20 2.42.4: b08e5e8a649dde8127857d5eea9152be6aa2de1e @@ -49175,13 +49175,13 @@ pages: 2.45.3: 2d2d9691d7219bf421bb4ce632b90295cc3a467d 2.46.3: fb6372d5c849d4357294e5f39d5af70e4ada408e 2.47.2: fc934ece0c6da2a4b94fc765f86ba70388d663f9 - 2.48.1: 7360d343bd22b796aa23b92375da5ec16d6841e6 + 2.48.1: 73ae4b8924e2c768a0a6ba30c01b634b977ea780 latest-changes: 2.48.0 page-versions: - name: 2.48.1 - name: 2.48.0 - added: 0 - removed: 8 + added: 8 + removed: 0 - name: 2.47.1 → 2.47.2 - name: 2.47.0 added: 8 @@ -49645,6 +49645,14 @@ pages: - 0 - 8 - 0 + fc934ece0c6da2a4b94fc765f86ba70388d663f9..73ae4b8924e2c768a0a6ba30c01b634b977ea780: + - 8 + - 0 + - 0 + 73ae4b8924e2c768a0a6ba30c01b634b977ea780..7360d343bd22b796aa23b92375da5ec16d6841e6: + - 0 + - 8 + - 0 languages: de: 3ec6cfaa1793e0bb0406b4fdcf0fdbd298b227b9 es: 02a15faf1f1e488266373359994658ec45fef7ae diff --git a/script/update-docs.rb b/script/update-docs.rb index b227ebcb3f..dec12c6ec7 100644 --- a/script/update-docs.rb +++ b/script/update-docs.rb @@ -48,7 +48,7 @@ def wrap_front_matter(front_matter) end def expand_l10n(path, content, get_f_content, categories) - content.gsub!(/include::(\S+)\.txt/) do |line| + content.gsub!(/include::({build_dir}\/)?(\S+)\.txt/) do |line| line.gsub!("include::", "") if categories[line] new_content = categories[line] @@ -240,7 +240,7 @@ def drop_uninteresting_tags(tags) end def expand_content(content, path, get_f_content, generated) - content.gsub(/include::(\S+)\.txt\[\]/) do |_line| + content.gsub(/include::(?:{build_dir}\/)?(\S+)\.txt\[\]/) do |_line| if File.dirname(path) == "." new_fname = "#{$1}.txt" else