summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/Makefile4
-rw-r--r--Documentation/MyFirstContribution.txt11
-rw-r--r--Documentation/RelNotes/2.29.0.txt514
-rw-r--r--Documentation/RelNotes/2.29.1.txt11
-rw-r--r--Documentation/RelNotes/2.29.2.txt12
-rw-r--r--Documentation/RelNotes/2.30.0.txt201
-rw-r--r--Documentation/SubmittingPatches43
-rw-r--r--Documentation/blame-options.txt15
-rwxr-xr-xDocumentation/cmd-list.perl27
-rw-r--r--Documentation/config.txt10
-rw-r--r--Documentation/config/advice.txt9
-rw-r--r--Documentation/config/checkout.txt21
-rw-r--r--Documentation/config/clone.txt4
-rw-r--r--Documentation/config/commitgraph.txt8
-rw-r--r--Documentation/config/core.txt6
-rw-r--r--Documentation/config/extensions.txt8
-rw-r--r--Documentation/config/feature.txt4
-rw-r--r--Documentation/config/fetch.txt5
-rw-r--r--Documentation/config/fmt-merge-msg.txt12
-rw-r--r--Documentation/config/format.txt6
-rw-r--r--Documentation/config/maintenance.txt59
-rw-r--r--Documentation/config/mergetool.txt10
-rw-r--r--Documentation/config/protocol.txt3
-rw-r--r--Documentation/config/push.txt6
-rw-r--r--Documentation/config/receive.txt22
-rw-r--r--Documentation/config/sendemail.txt5
-rw-r--r--Documentation/config/uploadpack.txt18
-rw-r--r--Documentation/diff-generate-patch.txt3
-rw-r--r--Documentation/diff-options.txt34
-rw-r--r--Documentation/fetch-options.txt17
-rw-r--r--Documentation/git-am.txt2
-rw-r--r--Documentation/git-apply.txt20
-rw-r--r--Documentation/git-archive.txt6
-rw-r--r--Documentation/git-bisect-lk2009.txt16
-rw-r--r--Documentation/git-bisect.txt15
-rw-r--r--Documentation/git-blame.txt4
-rw-r--r--Documentation/git-branch.txt18
-rw-r--r--Documentation/git-bundle.txt9
-rw-r--r--Documentation/git-checkout.txt10
-rw-r--r--Documentation/git-cherry-pick.txt2
-rw-r--r--Documentation/git-clone.txt11
-rw-r--r--Documentation/git-commit-graph.txt16
-rw-r--r--Documentation/git-commit.txt10
-rw-r--r--Documentation/git-diff-index.txt9
-rw-r--r--Documentation/git-diff-tree.txt7
-rw-r--r--Documentation/git-diff.txt36
-rw-r--r--Documentation/git-fast-import.txt2
-rw-r--r--Documentation/git-fetch.txt4
-rw-r--r--Documentation/git-filter-branch.txt2
-rw-r--r--Documentation/git-for-each-ref.txt52
-rw-r--r--Documentation/git-for-each-repo.txt59
-rw-r--r--Documentation/git-format-patch.txt2
-rw-r--r--Documentation/git-grep.txt8
-rw-r--r--Documentation/git-help.txt8
-rw-r--r--Documentation/git-imap-send.txt34
-rw-r--r--Documentation/git-index-pack.txt6
-rw-r--r--Documentation/git-init.txt4
-rw-r--r--Documentation/git-log.txt69
-rw-r--r--Documentation/git-ls-files.txt5
-rw-r--r--Documentation/git-ls-tree.txt3
-rw-r--r--Documentation/git-mailinfo.txt7
-rw-r--r--Documentation/git-maintenance.txt224
-rw-r--r--Documentation/git-multi-pack-index.txt11
-rw-r--r--Documentation/git-notes.txt2
-rw-r--r--Documentation/git-p4.txt2
-rw-r--r--Documentation/git-pack-objects.txt11
-rw-r--r--Documentation/git-push.txt26
-rw-r--r--Documentation/git-rebase.txt36
-rw-r--r--Documentation/git-remote.txt31
-rw-r--r--Documentation/git-restore.txt4
-rw-r--r--Documentation/git-rev-list.txt40
-rw-r--r--Documentation/git-revert.txt2
-rw-r--r--Documentation/git-send-email.txt4
-rw-r--r--Documentation/git-shortlog.txt31
-rw-r--r--Documentation/git-show-index.txt2
-rw-r--r--Documentation/git-svn.txt4
-rw-r--r--Documentation/git-switch.txt3
-rw-r--r--Documentation/git-tag.txt11
-rw-r--r--Documentation/git-update-ref.txt13
-rw-r--r--Documentation/git-worktree.txt163
-rw-r--r--Documentation/git.txt25
-rw-r--r--Documentation/gitattributes.txt3
-rw-r--r--Documentation/gitcredentials.txt2
-rw-r--r--Documentation/gitfaq.txt86
-rw-r--r--Documentation/githooks.txt70
-rw-r--r--Documentation/gitk.txt20
-rw-r--r--Documentation/gitsubmodules.txt23
-rw-r--r--Documentation/line-range-format.txt28
-rw-r--r--Documentation/line-range-options.txt15
-rw-r--r--Documentation/merge-options.txt11
-rw-r--r--Documentation/object-format-disclaimer.txt6
-rw-r--r--Documentation/pretty-options.txt10
-rw-r--r--Documentation/pull-fetch-param.txt16
-rw-r--r--Documentation/ref-reachability-filters.txt7
-rw-r--r--Documentation/rev-list-description.txt61
-rw-r--r--Documentation/rev-list-options.txt52
-rw-r--r--Documentation/revisions.txt3
-rw-r--r--Documentation/signoff-option.txt18
-rw-r--r--Documentation/technical/api-parse-options.txt4
-rw-r--r--Documentation/technical/bundle-format.txt30
-rw-r--r--Documentation/technical/commit-graph-format.txt15
-rw-r--r--Documentation/technical/commit-graph.txt6
-rw-r--r--Documentation/technical/directory-rename-detection.txt15
-rw-r--r--Documentation/technical/hash-function-transition.txt2
-rw-r--r--Documentation/technical/http-protocol.txt5
-rw-r--r--Documentation/technical/index-format.txt34
-rw-r--r--Documentation/technical/pack-format.txt43
-rw-r--r--Documentation/technical/pack-protocol.txt41
-rw-r--r--Documentation/technical/partial-clone.txt13
-rw-r--r--Documentation/technical/protocol-capabilities.txt29
-rw-r--r--Documentation/technical/shallow.txt2
111 files changed, 2338 insertions, 541 deletions
diff --git a/Documentation/Makefile b/Documentation/Makefile
index ecd0b34..80d1908 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -17,6 +17,7 @@ MAN1_TXT += git.txt
MAN1_TXT += gitk.txt
MAN1_TXT += gitweb.txt
+# man5 / man7 guides (note: new guides should also be added to command-list.txt)
MAN5_TXT += gitattributes.txt
MAN5_TXT += githooks.txt
MAN5_TXT += gitignore.txt
@@ -294,6 +295,7 @@ cmds_txt = cmds-ancillaryinterrogators.txt \
cmds-plumbingmanipulators.txt \
cmds-synchingrepositories.txt \
cmds-synchelpers.txt \
+ cmds-guide.txt \
cmds-purehelpers.txt \
cmds-foreignscminterface.txt
@@ -301,7 +303,7 @@ $(cmds_txt): cmd-list.made
cmd-list.made: cmd-list.perl ../command-list.txt $(MAN1_TXT)
$(QUIET_GEN)$(RM) $@ && \
- $(PERL_PATH) ./cmd-list.perl ../command-list.txt $(QUIET_STDERR) && \
+ $(PERL_PATH) ./cmd-list.perl ../command-list.txt $(cmds_txt) $(QUIET_STDERR) && \
date >$@
mergetools_txt = mergetools-diff.txt mergetools-merge.txt
diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt
index d85c9b5..60eed5e 100644
--- a/Documentation/MyFirstContribution.txt
+++ b/Documentation/MyFirstContribution.txt
@@ -249,7 +249,7 @@ component you're working on, followed by a blank line (always required) and then
the body of your commit message, which should provide the bulk of the context.
Remember to be explicit and provide the "Why" of your change, especially if it
couldn't easily be understood from your diff. When editing your commit message,
-don't remove the Signed-off-by line which was added by `-s` above.
+don't remove the `Signed-off-by` trailer which was added by `-s` above.
----
psuh: add a built-in by popular demand
@@ -319,14 +319,14 @@ function body:
...
git_config(git_default_config, NULL);
- if (git_config_get_string_const("user.name", &cfg_name) > 0)
+ if (git_config_get_string_tmp("user.name", &cfg_name) > 0)
printf(_("No name is found in config\n"));
else
printf(_("Your name: %s\n"), cfg_name);
----
`git_config()` will grab the configuration from config files known to Git and
-apply standard precedence rules. `git_config_get_string_const()` will look up
+apply standard precedence rules. `git_config_get_string_tmp()` will look up
a specific key ("user.name") and give you the value. There are a number of
single-key lookup functions like this one; you can see them all (and more info
about how to use `git_config()`) in `Documentation/technical/api-config.txt`.
@@ -507,6 +507,9 @@ documentation is consistent with other Git and UNIX manpages; this makes life
easier for your user, who can skip to the section they know contains the
information they need.
+NOTE: Before trying to build the docs, make sure you have the package `asciidoc`
+installed.
+
Now that you've written your manpage, you'll need to build it explicitly. We
convert your AsciiDoc to troff which is man-readable like so:
@@ -522,8 +525,6 @@ $ make -C Documentation/ git-psuh.1
$ man Documentation/git-psuh.1
----
-NOTE: You may need to install the package `asciidoc` to get this to work.
-
While this isn't as satisfying as running through `git help`, you can at least
check that your help page looks right.
diff --git a/Documentation/RelNotes/2.29.0.txt b/Documentation/RelNotes/2.29.0.txt
new file mode 100644
index 0000000..06ba2f8
--- /dev/null
+++ b/Documentation/RelNotes/2.29.0.txt
@@ -0,0 +1,514 @@
+Git 2.29 Release Notes
+======================
+
+Updates since v2.28
+-------------------
+
+UI, Workflows & Features
+
+ * "git help log" has been enhanced by sharing more material from the
+ documentation for the underlying "git rev-list" command.
+
+ * "git for-each-ref --format=<>" learned %(contents:size).
+
+ * "git merge" learned to selectively omit " into <branch>" at the end
+ of the title of default merge message with merge.suppressDest
+ configuration.
+
+ * The component to respond to "git fetch" request is made more
+ configurable to selectively allow or reject object filtering
+ specification used for partial cloning.
+
+ * Stop when "sendmail.*" configuration variables are defined, which
+ could be a mistaken attempt to define "sendemail.*" variables.
+
+ * The existing backends for "git mergetool" based on variants of vim
+ have been refactored and then support for "nvim" has been added.
+
+ * "git bisect" learns the "--first-parent" option to find the first
+ breakage along the first-parent chain.
+
+ * "git log --first-parent -p" showed patches only for single-parent
+ commits on the first-parent chain; the "--first-parent" option has
+ been made to imply "-m". Use "--no-diff-merges" to restore the
+ previous behaviour to omit patches for merge commits.
+
+ * The commit labels used to explain each side of conflicted hunks
+ placed by the sequencer machinery have been made more readable by
+ humans.
+
+ * The "--batch-size" option of "git multi-pack-index repack" command
+ is now used to specify that very small packfiles are collected into
+ one until the total size roughly exceeds it.
+
+ * The recent addition of SHA-256 support is marked as experimental in
+ the documentation.
+
+ * "git fetch" learned --no-write-fetch-head option to avoid writing
+ the FETCH_HEAD file.
+
+ * Command line completion (in contrib/) usually omits redundant,
+ deprecated and/or dangerous options from its output; it learned to
+ optionally include all of them.
+
+ * The output from the "diff" family of the commands had abbreviated
+ object names of blobs involved in the patch, but its length was not
+ affected by the --abbrev option. Now it is.
+
+ * "git worktree" gained a "repair" subcommand to help users recover
+ after moving the worktrees or repository manually without telling
+ Git. Also, "git init --separate-git-dir" no longer corrupts
+ administrative data related to linked worktrees.
+
+ * The "--format=" option to the "for-each-ref" command and friends
+ learned a few more tricks, e.g. the ":short" suffix that applies to
+ "objectname" now also can be used for "parent", "tree", etc.
+
+ * "git worktree add" learns that the "-d" is a synonym to "--detach"
+ option to create a new worktree without being on a branch.
+
+ * "format-patch --range-diff=<prev> <origin>..HEAD" has been taught
+ not to ignore <origin> when <prev> is a single version.
+
+ * "add -p" now allows editing paths that were only added in intent.
+
+ * The 'meld' backend of the "git mergetool" learned to give the
+ underlying 'meld' the '--auto-merge' option, which would help
+ reduce the amount of text that requires manual merging.
+
+ * "git for-each-ref" and friends that list refs used to allow only
+ one --merged or --no-merged to filter them; they learned to take
+ combination of both kind of filtering.
+
+ * "git maintenance", a "git gc"'s big brother, has been introduced to
+ take care of more repository maintenance tasks, not limited to the
+ object database cleaning.
+
+ * "git receive-pack" that accepts requests by "git push" learned to
+ outsource most of the ref updates to the new "proc-receive" hook.
+
+ * "git push" that wants to be atomic and wants to send push
+ certificate learned not to prepare and sign the push certificate
+ when it fails the local check (hence due to atomicity it is known
+ that no certificate is needed).
+
+ * "git commit-graph write" learned to limit the number of bloom
+ filters that are computed from scratch with the --max-new-filters
+ option.
+
+ * The transport protocol v2 has become the default again.
+
+ * The installation procedure learned to optionally omit "git-foo"
+ executable files for each 'foo' built-in subcommand, which are only
+ required by old timers that still rely on the age old promise that
+ prepending "git --exec-path" output to PATH early in their script
+ will keep the "git-foo" calls they wrote working.
+
+ * The command line completion (in contrib/) learned that "git restore
+ -s <TAB>" is often followed by a refname.
+
+ * "git shortlog" has been taught to group commits by the contents of
+ the trailer lines, like "Reviewed-by:", "Coauthored-by:", etc.
+
+ * "git archive" learns the "--add-file" option to include untracked
+ files into a snapshot from a tree-ish.
+
+ * "git fetch" and "git push" support negative refspecs.
+
+ * "git format-patch" learns to take "whenAble" as a possible value
+ for the format.useAutoBase configuration variable to become no-op
+ when the automatically computed base does not make sense.
+
+ * Credential helpers are now allowed to terminate lines with CRLF
+ line ending, as well as LF line ending.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The changed-path Bloom filter is improved using ideas from an
+ independent implementation.
+
+ * Updates to the changed-paths bloom filter.
+
+ * The test framework has been updated so that most tests will run
+ with predictable (artificial) timestamps.
+
+ * Preliminary clean-up of the refs API in preparation for adding a
+ new refs backend "reftable".
+
+ * Dev support to limit the use of test_must_fail to only git commands.
+
+ * While packing many objects in a repository with a promissor remote,
+ lazily fetching missing objects from the promissor remote one by
+ one may be inefficient---the code now attempts to fetch all the
+ missing objects in batch (obviously this won't work for a lazy
+ clone that lazily fetches tree objects as you cannot even enumerate
+ what blobs are missing until you learn which trees are missing).
+
+ * The pretend-object mechanism checks if the given object already
+ exists in the object store before deciding to keep the data
+ in-core, but the check would have triggered lazy fetching of such
+ an object from a promissor remote.
+
+ * The argv_array API is useful for not just managing argv but any
+ "vector" (NULL-terminated array) of strings, and has seen adoption
+ to a certain degree. It has been renamed to "strvec" to reduce the
+ barrier to adoption.
+
+ * The final leg of SHA-256 transition plus doc updates. Note that
+ there is no interoperability between SHA-1 and SHA-256
+ repositories yet.
+
+ * CMake support to build with MSVC for Windows bypassing the Makefile.
+
+ * A new helper function has_object() has been introduced to make it
+ easier to mark object existence checks that do and don't want to
+ trigger lazy fetches, and a few such checks are converted using it.
+
+ * A no-op replacement function implemented as a C preprocessor macro
+ does not perform as good a job as one implemented as a "static
+ inline" function in catching errors in parameters; replace the
+ former with the latter in <git-compat-util.h> header.
+
+ * Test framework update.
+ (merge d572f52a64 es/test-cmp-typocatcher later to maint).
+
+ * Updates to "git merge" tests, in preparation for a new merge
+ strategy backend.
+
+ * midx and commit-graph files now use the byte defined in their file
+ format specification for identifying the hash function used for
+ object names.
+
+ * The FETCH_HEAD is now always read from the filesystem regardless of
+ the ref backend in use, as its format is much richer than the
+ normal refs, and written directly by "git fetch" as a plain file..
+
+ * An unused binary has been discarded, and and a bunch of commands
+ have been turned into into built-in.
+
+ * A handful of places in in-tree code still relied on being able to
+ execute the git subcommands, especially built-ins, in "git-foo"
+ form, which have been corrected.
+
+ * When a packfile is removed by "git repack", multi-pack-index gets
+ cleared; the code was taught to do so less aggressively by first
+ checking if the midx actually refers to a pack that no longer
+ exists.
+
+ * Internal API clean-up to handle two options "diff-index" and "log"
+ have, which happen to share the same short form, more sensibly.
+
+ * The "add -i/-p" machinery has been written in C but it is not used
+ by default yet. It is made default to those who are participating
+ in feature.experimental experiment.
+
+ * Allow maintainers to tweak $(TAR) invocations done while making
+ distribution tarballs.
+
+ * "git index-pack" learned to resolve deltified objects with greater
+ parallelism.
+
+ * "diff-highlight" (in contrib/) had a logic to flush its output upon
+ seeing a blank line but the way it detected a blank line was broken.
+
+ * The logic to skip testing on the tagged commit and the tag itself
+ was not quite consistent which led to failure of Windows test
+ tasks. It has been revamped to consistently skip revisions that
+ have already been tested, based on the tree object of the revision.
+
+
+Fixes since v2.28
+-----------------
+
+ * The "mediawiki" remote backend which lives in contrib/mw-to-git/
+ and is not built with git by default, had an RCE bug allowing a
+ malicious MediaWiki server operator to inject arbitrary commands
+ for execution by a cloning client. This has been fixed.
+
+ The bug was discovered and reported by Joern Schneeweisz of GitLab
+ to the git-security mailing list. Its practical impact due to the
+ obscurity of git-remote-mediawiki was deemed small enough to forgo
+ a dedicated security release.
+
+ * "git clone --separate-git-dir=$elsewhere" used to stomp on the
+ contents of the existing directory $elsewhere, which has been
+ taught to fail when $elsewhere is not an empty directory.
+ (merge dfaa209a79 bw/fail-cloning-into-non-empty later to maint).
+
+ * With the base fix to 2.27 regresion, any new extensions in a v0
+ repository would still be silently honored, which is not quite
+ right. Instead, complain and die loudly.
+ (merge ec91ffca04 jk/reject-newer-extensions-in-v0 later to maint).
+
+ * Fetching from a lazily cloned repository resulted at the server
+ side in attempts to lazy fetch objects that the client side has,
+ many of which will not be available from the third-party anyway.
+ (merge 77aa0941ce jt/avoid-lazy-fetching-upon-have-check later to maint).
+
+ * Fix to an ancient bug caused by an over-eager attempt for
+ optimization.
+ (merge a98f7fb366 rs/add-index-entry-optim-fix later to maint).
+
+ * Pushing a ref whose name contains non-ASCII character with the
+ "--force-with-lease" option did not work over smart HTTP protocol,
+ which has been corrected.
+ (merge cd85b447bf bc/push-cas-cquoted-refname later to maint).
+
+ * "git mv src dst", when src is an unmerged path, errored out
+ correctly but with an incorrect error message to claim that src is
+ not tracked, which has been clarified.
+ (merge 9b906af657 ct/mv-unmerged-path-error later to maint).
+
+ * Fix to a regression introduced during 2.27 cycle.
+ (merge cada7308ad en/fill-directory-exponential later to maint).
+
+ * Command line completion (in contrib/) update.
+ (merge 688b87c81b mp/complete-show-color-moved later to maint).
+
+ * All "mergy" operations that internally use the merge-recursive
+ machinery should honor the merge.renormalize configuration, but
+ many of them didn't.
+
+ * Doc cleanup around "worktree".
+ (merge dc9c144be5 es/worktree-doc-cleanups later to maint).
+
+ * The "git blame --first-parent" option was not documented, but now
+ it is.
+ (merge 11bc12ae1e rp/blame-first-parent-doc later to maint).
+
+ * The logic to find the ref transaction hook script attempted to
+ cache the path to the found hook without realizing that it needed
+ to keep a copied value, as the API it used returned a transitory
+ buffer space. This has been corrected.
+ (merge 09b2aa30c9 ps/ref-transaction-hook later to maint).
+
+ * Recent versions of "git diff-files" shows a diff between the index
+ and the working tree for "intent-to-add" paths as a "new file"
+ patch; "git apply --cached" should be able to take "git diff-files"
+ and should act as an equivalent to "git add" for the path, but the
+ command failed to do so for such a path.
+ (merge 4c025c667e rp/apply-cached-with-i-t-a later to maint).
+
+ * "git diff [<tree-ish>] $path" for a $path that is marked with i-t-a
+ bit was not showing the mode bits from the working tree.
+ (merge cb0dd22b82 rp/ita-diff-modefix later to maint).
+
+ * Ring buffer with size 4 used for bin-hex translation resulted in a
+ wrong object name in the sequencer's todo output, which has been
+ corrected.
+ (merge 5da69c0dac ak/sequencer-fix-find-uniq-abbrev later to maint).
+
+ * When given more than one target line ranges, "git blame -La,b
+ -Lc,d" was over-eager to coalesce groups of original lines and
+ showed incorrect results, which has been corrected.
+ (merge c2ebaa27d6 jk/blame-coalesce-fix later to maint).
+
+ * The regexp to identify the function boundary for FORTRAN programs
+ has been updated.
+ (merge 75c3b6b2e8 pb/userdiff-fortran-update later to maint).
+
+ * A few end-user facing messages have been updated to be
+ hash-algorithm agnostic.
+ (merge 4279000d3e jc/object-names-are-not-sha-1 later to maint).
+
+ * "unlink" emulation on MinGW has been optimized.
+ (merge 680e0b4524 jh/mingw-unlink later to maint).
+
+ * The purpose of "git init --separate-git-dir" is to initialize a
+ new project with the repository separate from the working tree,
+ or, in the case of an existing project, to move the repository
+ (the .git/ directory) out of the working tree. It does not make
+ sense to use --separate-git-dir with a bare repository for which
+ there is no working tree, so disallow its use with bare
+ repositories.
+ (merge ccf236a23a es/init-no-separate-git-dir-in-bare later to maint).
+
+ * "ls-files -o" mishandled the top-level directory of another git
+ working tree that hangs in the current git working tree.
+ (merge ab282aa548 en/dir-nonbare-embedded later to maint).
+
+ * Fix some incorrect UNLEAK() annotations.
+ (merge 3e19816dc0 jk/unleak-fixes later to maint).
+
+ * Use more buffered I/O where we used to call many small write(2)s.
+ (merge a698d67b08 rs/more-buffered-io later to maint).
+
+ * The patch-id computation did not ignore the "incomplete last line"
+ marker like whitespaces.
+ (merge 82a62015a7 rs/patch-id-with-incomplete-line later to maint).
+
+ * Updates into a lazy/partial clone with a submodule did not work
+ well with transfer.fsckobjects set.
+
+ * The parser for "git for-each-ref --format=..." was too loose when
+ parsing the "%(trailers...)" atom, and forgot that "trailers" and
+ "trailers:<modifiers>" are the only two allowed forms, which has
+ been corrected.
+ (merge 2c22e102f8 hv/ref-filter-trailers-atom-parsing-fix later to maint).
+
+ * Long ago, we decided to use 3 threads by default when running the
+ index-pack task in parallel, which has been adjusted a bit upwards.
+ (merge fbff95b67f jk/index-pack-w-more-threads later to maint).
+
+ * "git restore/checkout --no-overlay" with wildcarded pathspec
+ mistakenly removed matching paths in subdirectories, which has been
+ corrected.
+ (merge bfda204ade rs/checkout-no-overlay-pathspec-fix later to maint).
+
+ * The description of --cached/--index options in "git apply --help"
+ has been updated.
+ (merge d064702be3 rp/apply-cached-doc later to maint).
+
+ * Feeding "$ZERO_OID" to "git log --ignore-missing --stdin", and
+ running "git log --ignore-missing $ZERO_OID" fell back to start
+ digging from HEAD; it has been corrected to become a no-op, like
+ "git log --tags=no-tag-matches-this-pattern" does.
+ (merge 04a0e98515 jk/rev-input-given-fix later to maint).
+
+ * Various callers of run_command API have been modernized.
+ (merge afbdba391e jc/run-command-use-embedded-args later to maint).
+
+ * List of options offered and accepted by "git add -i/-p" were
+ inconsistent, which have been corrected.
+ (merge ce910287e7 pw/add-p-allowed-options-fix later to maint).
+
+ * "git diff --stat -w" showed 0-line changes for paths whose changes
+ were only whitespaces, which was not intuitive. We now omit such
+ paths from the stat output.
+ (merge 1cf3d5db9b mr/diff-hide-stat-wo-textual-change later to maint).
+
+ * It was possible for xrealloc() to send a non-NULL pointer that has
+ been freed, which has been fixed.
+ (merge 6479ea4a8a jk/xrealloc-avoid-use-after-free later to maint).
+
+ * "git status" has trouble showing where it came from by interpreting
+ reflog entries that record certain events, e.g. "checkout @{u}", and
+ gives a hard/fatal error. Even though it inherently is impossible
+ to give a correct answer because the reflog entries lose some
+ information (e.g. "@{u}" does not record what branch the user was
+ on hence which branch 'the upstream' needs to be computed, and even
+ if the record were available, the relationship between branches may
+ have changed), at least hide the error and allow "status" to show its
+ output.
+
+ * "git status --short" quoted a path with SP in it when tracked, but
+ not those that are untracked, ignored or unmerged. They are all
+ shown quoted consistently.
+
+ * "git diff/show" on a change that involves a submodule used to read
+ the information on commits in the submodule from a wrong repository
+ and gave a wrong information when the commit-graph is involved.
+ (merge 85a1ec2c32 mf/submodule-summary-with-correct-repository later to maint).
+
+ * Unlike "git config --local", "git config --worktree" did not fail
+ early and cleanly when started outside a git repository.
+ (merge 378fe5fc3d mt/config-fail-nongit-early later to maint).
+
+ * There is a logic to estimate how many objects are in the
+ repository, which is meant to run once per process invocation, but
+ it ran every time the estimated value was requested.
+ (merge 67bb65de5d jk/dont-count-existing-objects-twice later to maint).
+
+ * "git remote set-head" that failed still said something that hints
+ the operation went through, which was misleading.
+ (merge 5a07c6c3c2 cs/don-t-pretend-a-failed-remote-set-head-succeeded later to maint).
+
+ * "git fetch --all --ipv4/--ipv6" forgot to pass the protocol options
+ to instances of the "git fetch" that talk to individual remotes,
+ which has been corrected.
+ (merge 4e735c1326 ar/fetch-ipversion-in-all later to maint).
+
+ * The "unshelve" subcommand of "git p4" incorrectly used commit^N
+ where it meant to say commit~N to name the Nth generation
+ ancestor, which has been corrected.
+ (merge 0acbf5997f ld/p4-unshelve-fix later to maint).
+
+ * "git clone" that clones from SHA-1 repository, while
+ GIT_DEFAULT_HASH set to use SHA-256 already, resulted in an
+ unusable repository that half-claims to be SHA-256 repository
+ with SHA-1 objects and refs. This has been corrected.
+
+ * Adjust sample hooks for hash algorithm other than SHA-1.
+ (merge d8d3d632f4 dl/zero-oid-in-hooks later to maint).
+
+ * "git range-diff" showed incorrect diffstat, which has been
+ corrected.
+
+ * Earlier we taught "git pull" to warn when the user does not say the
+ histories need to be merged, rebased or accepts only fast-
+ forwarding, but the warning triggered for those who have set the
+ pull.ff configuration variable.
+ (merge 54200cef86 ah/pull later to maint).
+
+ * Compilation fix around type punning.
+ (merge 176380fd11 jk/drop-unaligned-loads later to maint).
+
+ * "git blame --ignore-rev/--ignore-revs-file" failed to validate
+ their input are valid revision, and failed to take into account
+ that the user may want to give an annotated tag instead of a
+ commit, which has been corrected.
+ (merge 610e2b9240 jc/blame-ignore-fix later to maint).
+
+ * "git bisect start X Y", when X and Y are not valid committish
+ object names, should take X and Y as pathspec, but didn't.
+ (merge 73c6de06af cc/bisect-start-fix later to maint).
+
+ * The explanation of the "scissors line" has been clarified.
+ (merge 287416dba6 eg/mailinfo-doc-scissors later to maint).
+
+ * A race that leads to an access to a free'd data was corrected in
+ the codepath that reads pack files.
+ (merge bda959c476 mt/delta-base-cache-races later to maint).
+
+ * in_merge_bases_many(), a way to see if a commit is reachable from
+ any commit in a set of commits, was totally broken when the
+ commit-graph feature was in use, which has been corrected.
+ (merge 8791bf1841 ds/in-merge-bases-many-optim-bug later to maint).
+
+ * "git submodule update --quiet" did not squelch underlying "rebase"
+ and "pull" commands.
+ (merge 3ad0401e9e td/submodule-update-quiet later to maint).
+
+ * The lazy fetching done internally to make missing objects available
+ in a partial clone incorrectly made permanent damage to the partial
+ clone filter in the repository, which has been corrected.
+
+ * "log -c --find-object=X" did not work well to find a merge that
+ involves a change to an object X from only one parent.
+ (merge 957876f17d jk/diff-cc-oidfind-fix later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge 84544f2ea3 sk/typofixes later to maint).
+ (merge b17f411ab5 ar/help-guides-doc later to maint).
+ (merge 98c6871fad rs/grep-simpler-parse-object-or-die-call later to maint).
+ (merge 861c4ce141 en/typofixes later to maint).
+ (merge 60e47f6773 sg/ci-git-path-fix-with-pyenv later to maint).
+ (merge e2bfa50ac3 jb/doc-packfile-name later to maint).
+ (merge 918d8ff780 es/worktree-cleanup later to maint).
+ (merge dc156bc31f ma/t1450-quotefix later to maint).
+ (merge 56e743426b en/merge-recursive-comment-fixes later to maint).
+ (merge 7d23ff818f rs/bisect-oid-to-hex-fix later to maint).
+ (merge de20baf2c9 ny/notes-doc-sample-update later to maint).
+ (merge f649aaaf82 so/rev-parser-errormessage-fix later to maint).
+ (merge 6103d58b7f bc/sha-256-cvs-svn-updates later to maint).
+ (merge ac900fddb7 ma/stop-progress-null-fix later to maint).
+ (merge e767963ab6 rs/upload-pack-sigchain-fix later to maint).
+ (merge a831908599 rs/preserve-merges-unused-code-removal later to maint).
+ (merge 6dfefe70a9 jb/commit-graph-doc-fix later to maint).
+ (merge 847b37271e pb/set-url-docfix later to maint).
+ (merge 748f733d54 mt/checkout-entry-dead-code-removal later to maint).
+ (merge ce820cbd58 dl/subtree-docs later to maint).
+ (merge 55fe225dde jk/leakfix later to maint).
+ (merge ee22a29215 so/pretty-abbrev-doc later to maint).
+ (merge 3100fd5588 jc/post-checkout-doc later to maint).
+ (merge 17bae89476 pb/doc-external-diff-env later to maint).
+ (merge 27ed6ccc12 jk/worktree-check-clean-leakfix later to maint).
+ (merge 1302badd16 ea/blame-use-oideq later to maint).
+ (merge e6d5a11fed al/t3200-back-on-a-branch later to maint).
+ (merge 324efcf6b6 pw/add-p-leakfix later to maint).
+ (merge 1c6ffb546b jk/add-i-fixes later to maint).
+ (merge e40e936551 cd/commit-graph-doc later to maint).
+ (merge 0512eabd91 jc/sequencer-stopped-sha-simplify later to maint).
+ (merge d01141de5a so/combine-diff-simplify later to maint).
+ (merge 3be01e5ab1 sn/fast-import-doc later to maint).
diff --git a/Documentation/RelNotes/2.29.1.txt b/Documentation/RelNotes/2.29.1.txt
new file mode 100644
index 0000000..295ee21
--- /dev/null
+++ b/Documentation/RelNotes/2.29.1.txt
@@ -0,0 +1,11 @@
+Git v2.29.1 Release Notes
+=========================
+
+This is to fix the build procedure change in 2.28 where we failed to
+install a few programs that should be installed in /usr/bin (namely,
+receive-pack, upload-archive and upload-pack) when the non-default
+SKIP_DASHED_BUILT_INS installation option is in effect.
+
+A minor glitch in a non-default installation may usually not deserve
+a hotfix, but I know Git for Windows ship binaries built with this
+option, so let's make an exception.
diff --git a/Documentation/RelNotes/2.29.2.txt b/Documentation/RelNotes/2.29.2.txt
new file mode 100644
index 0000000..632b5b5
--- /dev/null
+++ b/Documentation/RelNotes/2.29.2.txt
@@ -0,0 +1,12 @@
+Git v2.29.2 Release Notes
+=========================
+
+This release is primarily to fix brown-paper-bag breakages in the
+2.29.0 release.
+
+Fixes since v2.29.1
+-------------------
+
+ * In 2.29, "--committer-date-is-author-date" option of "rebase" and
+ "am" subcommands lost the e-mail address by mistake, which has been
+ corrected.
diff --git a/Documentation/RelNotes/2.30.0.txt b/Documentation/RelNotes/2.30.0.txt
new file mode 100644
index 0000000..defa865
--- /dev/null
+++ b/Documentation/RelNotes/2.30.0.txt
@@ -0,0 +1,201 @@
+Git 2.30 Release Notes
+======================
+
+Updates since v2.29
+-------------------
+
+UI, Workflows & Features
+
+ * Userdiff for PHP update.
+
+ * Userdiff for Rust update.
+
+ * Userdiff for CSS update.
+
+ * The command line completion script (in contrib/) learned that "git
+ stash show" takes the options "git diff" takes.
+
+ * "git worktree list" now shows if each worktree is locked. This
+ possibly may open us to show other kinds of states in the future.
+
+ * "git maintenance", an extended big brother of "git gc", continues
+ to evolve.
+
+ * "git push --force-with-lease[=<ref>]" can easily be misused to lose
+ commits unless the user takes good care of their own "git fetch".
+ A new option "--force-if-includes" attempts to ensure that what is
+ being force-pushed was created after examining the commit at the
+ tip of the remote ref that is about to be force-replaced.
+
+ * "git clone" learned clone.defaultremotename configuration variable
+ to customize what nickname to use to call the remote the repository
+ was cloned from.
+
+ * "git checkout" learned to use checkout.guess configuration variable
+ and enable/disable its "--[no-]guess" option accordingly.
+
+ * "git resurrect" script (in contrib/) learned that the object names
+ may be longer than 40-hex depending on the hash function in use.
+
+ * "git diff A...B" learned "git diff --merge-base A B", which is a
+ longer short-hand to say the same thing.
+
+ * A sample 'push-to-checkout' hook, that performs the same as
+ what the built-in default action does, has been added.
+
+ * "git diff" family of commands learned the "-I<regex>" option to
+ ignore hunks whose changed lines all match the given pattern.
+
+ * The userdiff pattern learned to identify the function definition in
+ POSIX shells and bash.
+
+ * "git checkout-index" did not consistently signal an error with its
+ exit status, but now it does.
+
+ * A commit and tag object may have CR at the end of each and
+ every line (you can create such an object with hash-object or
+ using --cleanup=verbatim to decline the default clean-up
+ action), but it would make it impossible to have a blank line
+ to separate the title from the body of the message. We are now
+ more lenient and accept a line with lone CR on it as a blank line,
+ too.
+
+ * Exit codes from "git remote add" etc. were not usable by scripted
+ callers, but now they are.
+
+ * Zsh autocompletion (in contrib/) update.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Use "git archive" more to produce the release tarball.
+
+ * GitHub Actions automated test improvement to skip tests on a tree
+ identical to what has already been tested.
+
+ * Test-coverage for running commit-graph task "git maintenance" has
+ been extended.
+
+ * Our test scripts can be told to run only individual pieces while
+ skipping others with the "--run=..." option; they were taught to
+ take a substring of test title, in addition to numbers, to name the
+ test pieces to run.
+
+ * Adjust tests so that they won't scream when the default initial
+ branch name is changed to 'main'.
+
+ * Rewriting "git bisect" in C continues.
+
+ * More preliminary tests have been added to document desired outcome
+ of various "directory rename" situations.
+
+ * Micro clean-up of a couple of test scripts.
+
+ * "git diff" and other commands that share the same machinery to
+ compare with working tree files have been taught to take advantage
+ of the fsmonitor data when available.
+
+ * The code to detect premature EOF in the sideband demultiplexer has
+ been cleaned up.
+
+ * Test scripts are being prepared to transition of the default branch
+ name to 'main'.
+
+
+
+Fixes since v2.29
+-----------------
+
+ * In 2.29, "--committer-date-is-author-date" option of "rebase" and
+ "am" subcommands lost the e-mail address by mistake, which has been
+ corrected.
+ (merge 5f35edd9d7 jk/committer-date-is-author-date-fix later to maint).
+
+ * "git checkout -p A...B [-- <path>]" did not work, even though the
+ same command without "-p" correctly used the merge-base between
+ commits A and B.
+ (merge 35166b1fb5 dl/checkout-p-merge-base later to maint).
+
+ * The side-band status report can be sent at the same time as the
+ primary payload multiplexed, but the demultiplexer on the receiving
+ end incorrectly split a single status report into two, which has
+ been corrected.
+ (merge 712b0377db js/avoid-split-sideband-message later to maint).
+
+ * "git fast-import" wasted a lot of memory when many marks were in use.
+ (merge 3f018ec716 jk/fast-import-marks-alloc-fix later to maint).
+
+ * A test helper "test_cmp A B" was taught to diagnose missing files A
+ or B as a bug in test, but some tests legitimately wanted to notice
+ a failure to even create file B as an error, in addition to leaving
+ the expected result in it, and were misdiagnosed as a bug. This
+ has been corrected.
+ (merge 262d5ad5a5 es/test-cmp-typocatcher later to maint).
+
+ * When "git commit-graph" detects the same commit recorded more than
+ once while it is merging the layers, it used to die. The code now
+ ignores all but one of them and continues.
+ (merge 85102ac71b ds/commit-graph-merging-fix later to maint).
+
+ * The meaning of a Signed-off-by trailer can vary from project to
+ project; this and also what it means to this project has been
+ clarified in the documentation.
+ (merge 3abd4a67d9 bk/sob-dco later to maint).
+
+ * "git credential' didn't honor the core.askPass configuration
+ variable (among other things), which has been corrected.
+ (merge 567ad2c0f9 tk/credential-config later to maint).
+
+ * Dev support to catch a tentative definition of a variable in our C
+ code as an error.
+ (merge 5539183622 jk/no-common later to maint).
+
+ * "git rebase --rebase-merges" did not correctly pass --gpg-sign
+ command line option to underlying "git merge" when replaying a merge
+ using non-default merge strategy or when replaying an octopus merge
+ (because replaying a two-head merge with the default strategy was
+ done in a separate codepath, the problem did not trigger for most
+ users), which has been corrected.
+ (merge 43ad4f2eca sc/sequencer-gpg-octopus later to maint).
+
+ * "git apply -R" did not handle patches that touch the same path
+ twice correctly, which has been corrected. This is most relevant
+ in a patch that changes a path from a regular file to a symbolic
+ link (and vice versa).
+ (merge b0f266de11 jt/apply-reverse-twice later to maint).
+
+ * A recent oid->hash conversion missed one spot, breaking "git svn".
+ (merge 03bb366de4 bc/svn-hash-oid-fix later to maint).
+
+ * The documentation on the "--abbrev=<n>" option did not say the
+ output may be longer than "<n>" hexdigits, which has been
+ clarified.
+ (merge cda34e0d0c jc/abbrev-doc later to maint).
+
+ * "git p4" now honors init.defaultBranch configuration.
+ (merge 1b09d1917f js/p4-default-branch later to maint).
+
+ * Recently the format of an internal state file "rebase -i" uses has
+ been tightened up for consistency, which would hurt those who start
+ "rebase -i" with old git and then continue with new git. Loosen
+ the reader side a bit (which we may want to tighten again in a year
+ or so).
+ (merge c779386182 jc/sequencer-stopped-sha-simplify later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge 3e0a5dc9af cc/doc-filter-branch-typofix later to maint).
+ (merge 32c83afc2c cw/ci-ghwf-check-ws-errors later to maint).
+ (merge 5eb2ed691b rs/tighten-callers-of-deref-tag later to maint).
+ (merge 6db29ab213 jk/fast-import-marks-cleanup later to maint).
+ (merge e5cf6d3df4 nk/dir-c-comment-update later to maint).
+ (merge 5710dcce74 jk/report-fn-typedef later to maint).
+ (merge 9a82db1056 en/sequencer-rollback-lock-cleanup later to maint).
+ (merge 4e1bee9a99 js/t7006-cleanup later to maint).
+ (merge f5bcde6c58 es/tutorial-mention-asciidoc-early later to maint).
+ (merge 714d491af0 so/format-patch-doc-on-default-diff-format later to maint).
+ (merge 0795df4b9b rs/clear-commit-marks-in-repo later to maint).
+ (merge 9542d56379 sd/prompt-local-variable later to maint).
+ (merge 06d43fad18 rs/pack-write-hashwrite-simplify later to maint).
+ (merge b7e20b4373 mc/typofix later to maint).
+ (merge f6bcd9a8a4 js/test-whitespace-fixes later to maint).
+ (merge 53b67a801b js/test-file-size later to maint).
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 291b61e..d12094b 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -209,7 +209,7 @@ send them as replies to either an additional "cover letter" message
(see below), the first patch, or the respective preceding patch.
If your log message (including your name on the
-Signed-off-by line) is not writable in ASCII, make sure that
+`Signed-off-by` trailer) is not writable in ASCII, make sure that
you send off a message in the correct encoding.
WARNING: Be wary of your MUAs word-wrap
@@ -229,7 +229,7 @@ previously sent.
The `git format-patch` command follows the best current practice to
format the body of an e-mail message. At the beginning of the
patch should come your commit message, ending with the
-Signed-off-by: lines, and a line that consists of three dashes,
+`Signed-off-by` trailers, and a line that consists of three dashes,
followed by the diffstat information and the patch itself. If
you are forwarding a patch from somebody else, optionally, at
the beginning of the e-mail message just before the commit
@@ -290,25 +290,24 @@ identify them), to solicit comments and reviews.
:git-ml: footnote:[The mailing list: git@vger.kernel.org]
After the list reached a consensus that it is a good idea to apply the
-patch, re-send it with "To:" set to the maintainer{current-maintainer} and "cc:" the
-list{git-ml} for inclusion.
+patch, re-send it with "To:" set to the maintainer{current-maintainer}
+and "cc:" the list{git-ml} for inclusion. This is especially relevant
+when the maintainer did not heavily participate in the discussion and
+instead left the review to trusted others.
Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and
`Tested-by:` lines as necessary to credit people who helped your
-patch.
+patch, and "cc:" them when sending such a final version for inclusion.
[[sign-off]]
-=== Certify your work by adding your "Signed-off-by: " line
+=== Certify your work by adding your `Signed-off-by` trailer
-To improve tracking of who did what, we've borrowed the
-"sign-off" procedure from the Linux kernel project on patches
-that are being emailed around. Although core Git is a lot
-smaller project it is a good discipline to follow it.
+To improve tracking of who did what, we ask you to certify that you
+wrote the patch or have the right to pass it on under the same license
+as ours, by "signing off" your patch. Without sign-off, we cannot
+accept your patches.
-The sign-off is a simple line at the end of the explanation for
-the patch, which certifies that you wrote it or otherwise have
-the right to pass it on as an open-source patch. The rules are
-pretty simple: if you can certify the below D-C-O:
+If you can certify the below D-C-O:
[[dco]]
.Developer's Certificate of Origin 1.1
@@ -338,23 +337,29 @@ d. I understand and agree that this project and the contribution
this project or the open source license(s) involved.
____
-then you just add a line saying
+you add a "Signed-off-by" trailer to your commit, that looks like
+this:
....
Signed-off-by: Random J Developer <random@developer.example.org>
....
-This line can be automatically added by Git if you run the git-commit
-command with the -s option.
+This line can be added by Git if you run the git-commit command with
+the -s option.
-Notice that you can place your own Signed-off-by: line when
+Notice that you can place your own `Signed-off-by` trailer when
forwarding somebody else's patch with the above rules for
D-C-O. Indeed you are encouraged to do so. Do not forget to
place an in-body "From: " line at the beginning to properly attribute
the change to its true author (see (2) above).
+This procedure originally came from the Linux kernel project, so our
+rule is quite similar to theirs, but what exactly it means to sign-off
+your patch differs from project to project, so it may be different
+from that of the project you are accustomed to.
+
[[real-name]]
-Also notice that a real name is used in the Signed-off-by: line. Please
+Also notice that a real name is used in the `Signed-off-by` trailer. Please
don't hide your real name.
[[commit-trailers]]
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index 5d122db..dc3bceb 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -11,11 +11,12 @@
-L <start>,<end>::
-L :<funcname>::
- Annotate only the given line range. May be specified multiple times.
- Overlapping ranges are allowed.
+ Annotate only the line range given by '<start>,<end>',
+ or by the function name regex '<funcname>'.
+ May be specified multiple times. Overlapping ranges are allowed.
+
-<start> and <end> are optional. ``-L <start>'' or ``-L <start>,'' spans from
-<start> to end of file. ``-L ,<end>'' spans from start of file to <end>.
+'<start>' and '<end>' are optional. `-L <start>` or `-L <start>,` spans from
+'<start>' to end of file. `-L ,<end>` spans from start of file to '<end>'.
+
include::line-range-format.txt[]
@@ -36,6 +37,12 @@ include::line-range-format.txt[]
START. `git blame --reverse START` is taken as `git blame
--reverse START..HEAD` for convenience.
+--first-parent::
+ Follow only the first parent commit upon seeing a merge
+ commit. This option can be used to determine when a line
+ was introduced to a particular integration branch, rather
+ than when it was introduced to the history overall.
+
-p::
--porcelain::
Show in a format designed for machine consumption.
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
index 5aa73cf..af5da45 100755
--- a/Documentation/cmd-list.perl
+++ b/Documentation/cmd-list.perl
@@ -6,9 +6,14 @@ sub format_one {
my ($out, $nameattr) = @_;
my ($name, $attr) = @$nameattr;
my ($state, $description);
+ my $mansection;
$state = 0;
open I, '<', "$name.txt" or die "No such file $name.txt";
while (<I>) {
+ if (/^git[a-z0-9-]*\(([0-9])\)$/) {
+ $mansection = $1;
+ next;
+ }
if (/^NAME$/) {
$state = 1;
next;
@@ -27,7 +32,7 @@ sub format_one {
die "No description found in $name.txt";
}
if (my ($verify_name, $text) = ($description =~ /^($name) - (.*)/)) {
- print $out "linkgit:$name\[1\]::\n\t";
+ print $out "linkgit:$name\[$mansection\]::\n\t";
if ($attr =~ / deprecated /) {
print $out "(deprecated) ";
}
@@ -38,12 +43,15 @@ sub format_one {
}
}
-while (<>) {
+my ($input, @categories) = @ARGV;
+
+open IN, "<$input";
+while (<IN>) {
last if /^### command list/;
}
my %cmds = ();
-for (sort <>) {
+for (sort <IN>) {
next if /^#/;
chomp;
@@ -51,17 +59,10 @@ for (sort <>) {
$attr = '' unless defined $attr;
push @{$cmds{$cat}}, [$name, " $attr "];
}
+close IN;
-for my $cat (qw(ancillaryinterrogators
- ancillarymanipulators
- mainporcelain
- plumbinginterrogators
- plumbingmanipulators
- synchingrepositories
- foreignscminterface
- purehelpers
- synchelpers)) {
- my $out = "cmds-$cat.txt";
+for my $out (@categories) {
+ my ($cat) = $out =~ /^cmds-(.*)\.txt$/;
open O, '>', "$out+" or die "Cannot open output file $out+";
for (@{$cmds{$cat}}) {
format_one(\*O, $_);
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ef0768b..f292c26 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -265,7 +265,7 @@ color::
The basic colors accepted are `normal`, `black`, `red`, `green`, `yellow`,
`blue`, `magenta`, `cyan` and `white`. The first color given is the
foreground; the second is the background. All the basic colors except
-`normal` have a bright variant that can be speficied by prefixing the
+`normal` have a bright variant that can be specified by prefixing the
color with `bright`, like `brightred`.
+
Colors may also be given as numbers between 0 and 255; these use ANSI
@@ -334,12 +334,16 @@ include::config/checkout.txt[]
include::config/clean.txt[]
+include::config/clone.txt[]
+
include::config/color.txt[]
include::config/column.txt[]
include::config/commit.txt[]
+include::config/commitgraph.txt[]
+
include::config/credential.txt[]
include::config/completion.txt[]
@@ -348,6 +352,8 @@ include::config/diff.txt[]
include::config/difftool.txt[]
+include::config/extensions.txt[]
+
include::config/fastimport.txt[]
include::config/feature.txt[]
@@ -396,6 +402,8 @@ include::config/mailinfo.txt[]
include::config/mailmap.txt[]
+include::config/maintenance.txt[]
+
include::config/man.txt[]
include::config/merge.txt[]
diff --git a/Documentation/config/advice.txt b/Documentation/config/advice.txt
index bdd37c3..acbd0c0 100644
--- a/Documentation/config/advice.txt
+++ b/Documentation/config/advice.txt
@@ -10,9 +10,8 @@ advice.*::
that the check is disabled.
pushUpdateRejected::
Set this variable to 'false' if you want to disable
- 'pushNonFFCurrent',
- 'pushNonFFMatching', 'pushAlreadyExists',
- 'pushFetchFirst', and 'pushNeedsForce'
+ 'pushNonFFCurrent', 'pushNonFFMatching', 'pushAlreadyExists',
+ 'pushFetchFirst', 'pushNeedsForce', and 'pushRefNeedsUpdate'
simultaneously.
pushNonFFCurrent::
Advice shown when linkgit:git-push[1] fails due to a
@@ -41,6 +40,10 @@ advice.*::
we can still suggest that the user push to either
refs/heads/* or refs/tags/* based on the type of the
source object.
+ pushRefNeedsUpdate::
+ Shown when linkgit:git-push[1] rejects a forced update of
+ a branch when its remote-tracking ref has updates that we
+ do not have locally.
statusAheadBehind::
Shown when linkgit:git-status[1] computes the ahead/behind
counts for a local ref compared to its remote tracking ref,
diff --git a/Documentation/config/checkout.txt b/Documentation/config/checkout.txt
index 6b64681..2cddf7b 100644
--- a/Documentation/config/checkout.txt
+++ b/Documentation/config/checkout.txt
@@ -1,18 +1,23 @@
checkout.defaultRemote::
- When you run 'git checkout <something>'
- or 'git switch <something>' and only have one
+ When you run `git checkout <something>`
+ or `git switch <something>` and only have one
remote, it may implicitly fall back on checking out and
- tracking e.g. 'origin/<something>'. This stops working as soon
- as you have more than one remote with a '<something>'
+ tracking e.g. `origin/<something>`. This stops working as soon
+ as you have more than one remote with a `<something>`
reference. This setting allows for setting the name of a
preferred remote that should always win when it comes to
disambiguation. The typical use-case is to set this to
`origin`.
+
Currently this is used by linkgit:git-switch[1] and
-linkgit:git-checkout[1] when 'git checkout <something>'
-or 'git switch <something>'
-will checkout the '<something>' branch on another remote,
-and by linkgit:git-worktree[1] when 'git worktree add' refers to a
+linkgit:git-checkout[1] when `git checkout <something>`
+or `git switch <something>`
+will checkout the `<something>` branch on another remote,
+and by linkgit:git-worktree[1] when `git worktree add` refers to a
remote branch. This setting might be used for other checkout-like
commands or functionality in the future.
+
+checkout.guess::
+ Provides the default value for the `--guess` or `--no-guess`
+ option in `git checkout` and `git switch`. See
+ linkgit:git-switch[1] and linkgit:git-checkout[1].
diff --git a/Documentation/config/clone.txt b/Documentation/config/clone.txt
new file mode 100644
index 0000000..47de36a
--- /dev/null
+++ b/Documentation/config/clone.txt
@@ -0,0 +1,4 @@
+clone.defaultRemoteName::
+ The name of the remote to create when cloning a repository. Defaults to
+ `origin`, and can be overridden by passing the `--origin` command-line
+ option to linkgit:git-clone[1].
diff --git a/Documentation/config/commitgraph.txt b/Documentation/config/commitgraph.txt
new file mode 100644
index 0000000..4582c39
--- /dev/null
+++ b/Documentation/config/commitgraph.txt
@@ -0,0 +1,8 @@
+commitGraph.maxNewFilters::
+ Specifies the default value for the `--max-new-filters` option of `git
+ commit-graph write` (c.f., linkgit:git-commit-graph[1]).
+
+commitGraph.readChangedPaths::
+ If true, then git will use the changed-path Bloom filters in the
+ commit-graph file (if it exists, and they are present). Defaults to
+ true. See linkgit:git-commit-graph[1] for more information.
diff --git a/Documentation/config/core.txt b/Documentation/config/core.txt
index 74619a9..160aaca 100644
--- a/Documentation/config/core.txt
+++ b/Documentation/config/core.txt
@@ -399,7 +399,7 @@ the largest projects. You probably do not need to adjust this value.
Common unit suffixes of 'k', 'm', or 'g' are supported.
core.deltaBaseCacheLimit::
- Maximum number of bytes to reserve for caching base objects
+ Maximum number of bytes per thread to reserve for caching base objects
that may be referenced by multiple deltified objects. By storing the
entire decompressed base objects in a cache Git is able
to avoid unpacking and decompressing frequently used base
@@ -606,8 +606,8 @@ core.useReplaceRefs::
core.multiPackIndex::
Use the multi-pack-index file to track multiple packfiles using a
- single index. See link:technical/multi-pack-index.html[the
- multi-pack-index design document].
+ single index. See linkgit:git-multi-pack-index[1] for more
+ information. Defaults to true.
core.sparseCheckout::
Enable "sparse checkout" feature. See linkgit:git-sparse-checkout[1]
diff --git a/Documentation/config/extensions.txt b/Documentation/config/extensions.txt
new file mode 100644
index 0000000..4e23d73
--- /dev/null
+++ b/Documentation/config/extensions.txt
@@ -0,0 +1,8 @@
+extensions.objectFormat::
+ Specify the hash algorithm to use. The acceptable values are `sha1` and
+ `sha256`. If not specified, `sha1` is assumed. It is an error to specify
+ this key unless `core.repositoryFormatVersion` is 1.
++
+Note that this setting should only be set by linkgit:git-init[1] or
+linkgit:git-clone[1]. Trying to change it after initialization will not
+work and will produce hard-to-diagnose issues.
diff --git a/Documentation/config/feature.txt b/Documentation/config/feature.txt
index c0cbf2b..cdecd04 100644
--- a/Documentation/config/feature.txt
+++ b/Documentation/config/feature.txt
@@ -14,10 +14,6 @@ feature.experimental::
+
* `fetch.negotiationAlgorithm=skipping` may improve fetch negotiation times by
skipping more commits at a time, reducing the number of round trips.
-+
-* `protocol.version=2` speeds up fetches from repositories with many refs by
-allowing the client to specify which refs to list before the server lists
-them.
feature.manyFiles::
Enable config options that optimize for repos with many files in the
diff --git a/Documentation/config/fetch.txt b/Documentation/config/fetch.txt
index b203940..6af6f5e 100644
--- a/Documentation/config/fetch.txt
+++ b/Documentation/config/fetch.txt
@@ -60,7 +60,10 @@ fetch.negotiationAlgorithm::
sent when negotiating the contents of the packfile to be sent by the
server. Set to "skipping" to use an algorithm that skips commits in an
effort to converge faster, but may result in a larger-than-necessary
- packfile; The default is "default" which instructs Git to use the default algorithm
+ packfile; or set to "noop" to not send any information at all, which
+ will almost certainly result in a larger-than-necessary packfile, but
+ will skip the negotiation step.
+ The default is "default" which instructs Git to use the default algorithm
that never skips commits (unless the server has acknowledged it or one
of its descendants). If `feature.experimental` is enabled, then this
setting defaults to "skipping".
diff --git a/Documentation/config/fmt-merge-msg.txt b/Documentation/config/fmt-merge-msg.txt
index c73cfa9..3fbf40e 100644
--- a/Documentation/config/fmt-merge-msg.txt
+++ b/Documentation/config/fmt-merge-msg.txt
@@ -8,3 +8,15 @@ merge.log::
most the specified number of one-line descriptions from the
actual commits that are being merged. Defaults to false, and
true is a synonym for 20.
+
+merge.suppressDest::
+ By adding a glob that matches the names of integration
+ branches to this multi-valued configuration variable, the
+ default merge message computed for merges into these
+ integration branches will omit "into <branch name>" from
+ its title.
++
+An element with an empty value can be used to clear the list
+of globs accumulated from previous configuration entries.
+When there is no `merge.suppressDest` variable defined, the
+default value of `master` is used for backward compatibility.
diff --git a/Documentation/config/format.txt b/Documentation/config/format.txt
index 564e809..851bf41 100644
--- a/Documentation/config/format.txt
+++ b/Documentation/config/format.txt
@@ -79,7 +79,7 @@ format.thread::
format.signOff::
A boolean value which lets you enable the `-s/--signoff` option of
- format-patch by default. *Note:* Adding the Signed-off-by: line to a
+ format-patch by default. *Note:* Adding the `Signed-off-by` trailer to a
patch should be a conscious act and means that you certify you have
the rights to submit this work under the same open source license.
Please see the 'SubmittingPatches' document for further discussion.
@@ -96,7 +96,9 @@ format.outputDirectory::
format.useAutoBase::
A boolean value which lets you enable the `--base=auto` option of
- format-patch by default.
+ format-patch by default. Can also be set to "whenAble" to allow
+ enabling `--base=auto` if a suitable base is available, but to skip
+ adding base info otherwise without the format dying.
format.notes::
Provides the default value for the `--notes` option to
diff --git a/Documentation/config/maintenance.txt b/Documentation/config/maintenance.txt
new file mode 100644
index 0000000..a5ead09
--- /dev/null
+++ b/Documentation/config/maintenance.txt
@@ -0,0 +1,59 @@
+maintenance.auto::
+ This boolean config option controls whether some commands run
+ `git maintenance run --auto` after doing their normal work. Defaults
+ to true.
+
+maintenance.strategy::
+ This string config option provides a way to specify one of a few
+ recommended schedules for background maintenance. This only affects
+ which tasks are run during `git maintenance run --schedule=X`
+ commands, provided no `--task=<task>` arguments are provided.
+ Further, if a `maintenance.<task>.schedule` config value is set,
+ then that value is used instead of the one provided by
+ `maintenance.strategy`. The possible strategy strings are:
++
+* `none`: This default setting implies no task are run at any schedule.
+* `incremental`: This setting optimizes for performing small maintenance
+ activities that do not delete any data. This does not schedule the `gc`
+ task, but runs the `prefetch` and `commit-graph` tasks hourly and the
+ `loose-objects` and `incremental-repack` tasks daily.
+
+maintenance.<task>.enabled::
+ This boolean config option controls whether the maintenance task
+ with name `<task>` is run when no `--task` option is specified to
+ `git maintenance run`. These config values are ignored if a
+ `--task` option exists. By default, only `maintenance.gc.enabled`
+ is true.
+
+maintenance.<task>.schedule::
+ This config option controls whether or not the given `<task>` runs
+ during a `git maintenance run --schedule=<frequency>` command. The
+ value must be one of "hourly", "daily", or "weekly".
+
+maintenance.commit-graph.auto::
+ This integer config option controls how often the `commit-graph` task
+ should be run as part of `git maintenance run --auto`. If zero, then
+ the `commit-graph` task will not run with the `--auto` option. A
+ negative value will force the task to run every time. Otherwise, a
+ positive value implies the command should run when the number of
+ reachable commits that are not in the commit-graph file is at least
+ the value of `maintenance.commit-graph.auto`. The default value is
+ 100.
+
+maintenance.loose-objects.auto::
+ This integer config option controls how often the `loose-objects` task
+ should be run as part of `git maintenance run --auto`. If zero, then
+ the `loose-objects` task will not run with the `--auto` option. A
+ negative value will force the task to run every time. Otherwise, a
+ positive value implies the command should run when the number of
+ loose objects is at least the value of `maintenance.loose-objects.auto`.
+ The default value is 100.
+
+maintenance.incremental-repack.auto::
+ This integer config option controls how often the `incremental-repack`
+ task should be run as part of `git maintenance run --auto`. If zero,
+ then the `incremental-repack` task will not run with the `--auto`
+ option. A negative value will force the task to run every time.
+ Otherwise, a positive value implies the command should run when the
+ number of pack-files not in the multi-pack-index is at least the value
+ of `maintenance.incremental-repack.auto`. The default value is 10.
diff --git a/Documentation/config/mergetool.txt b/Documentation/config/mergetool.txt
index 09ed31d..16a2744 100644
--- a/Documentation/config/mergetool.txt
+++ b/Documentation/config/mergetool.txt
@@ -30,6 +30,16 @@ mergetool.meld.hasOutput::
to `true` tells Git to unconditionally use the `--output` option,
and `false` avoids using `--output`.
+mergetool.meld.useAutoMerge::
+ When the `--auto-merge` is given, meld will merge all non-conflicting
+ parts automatically, highlight the conflicting parts and wait for
+ user decision. Setting `mergetool.meld.useAutoMerge` to `true` tells
+ Git to unconditionally use the `--auto-merge` option with `meld`.
+ Setting this value to `auto` makes git detect whether `--auto-merge`
+ is supported and will only use `--auto-merge` when available. A
+ value of `false` avoids using `--auto-merge` altogether, and is the
+ default value.
+
mergetool.keepBackup::
After performing a merge, the original file with conflict markers
can be saved as a file with a `.orig` extension. If this variable
diff --git a/Documentation/config/protocol.txt b/Documentation/config/protocol.txt
index c46e9b3..756591d 100644
--- a/Documentation/config/protocol.txt
+++ b/Documentation/config/protocol.txt
@@ -48,8 +48,7 @@ protocol.version::
If set, clients will attempt to communicate with a server
using the specified protocol version. If the server does
not support it, communication falls back to version 0.
- If unset, the default is `0`, unless `feature.experimental`
- is enabled, in which case the default is `2`.
+ If unset, the default is `2`.
Supported versions:
+
--
diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt
index f5e5b38..21b256e 100644
--- a/Documentation/config/push.txt
+++ b/Documentation/config/push.txt
@@ -114,3 +114,9 @@ push.recurseSubmodules::
specifying '--recurse-submodules=check|on-demand|no'.
If not set, 'no' is used by default, unless 'submodule.recurse' is
set (in which case a 'true' value means 'on-demand').
+
+push.useForceIfIncludes::
+ If set to "true", it is equivalent to specifying
+ `--force-if-includes` as an option to linkgit:git-push[1]
+ in the command line. Adding `--no-force-if-includes` at the
+ time of push overrides this configuration setting.
diff --git a/Documentation/config/receive.txt b/Documentation/config/receive.txt
index 65f78aa..85d5b5a 100644
--- a/Documentation/config/receive.txt
+++ b/Documentation/config/receive.txt
@@ -114,6 +114,28 @@ receive.hideRefs::
An attempt to update or delete a hidden ref by `git push` is
rejected.
+receive.procReceiveRefs::
+ This is a multi-valued variable that defines reference prefixes
+ to match the commands in `receive-pack`. Commands matching the
+ prefixes will be executed by an external hook "proc-receive",
+ instead of the internal `execute_commands` function. If this
+ variable is not defined, the "proc-receive" hook will never be
+ used, and all commands will be executed by the internal
+ `execute_commands` function.
++
+For example, if this variable is set to "refs/for", pushing to reference
+such as "refs/for/master" will not create or update a reference named
+"refs/for/master", but may create or update a pull request directly by
+running the hook "proc-receive".
++
+Optional modifiers can be provided in the beginning of the value to filter
+commands for specific actions: create (a), modify (m), delete (d).
+A `!` can be included in the modifiers to negate the reference prefix entry.
+E.g.:
++
+ git config --system --add receive.procReceiveRefs ad:refs/heads
+ git config --system --add receive.procReceiveRefs !:refs/heads
+
receive.updateServerInfo::
If set to true, git-receive-pack will run git-update-server-info
after receiving data from git-push and updating refs.
diff --git a/Documentation/config/sendemail.txt b/Documentation/config/sendemail.txt
index 0006faf..cbc5af4 100644
--- a/Documentation/config/sendemail.txt
+++ b/Documentation/config/sendemail.txt
@@ -61,3 +61,8 @@ sendemail.smtpBatchSize::
sendemail.smtpReloginDelay::
Seconds wait before reconnecting to smtp server.
See also the `--relogin-delay` option of linkgit:git-send-email[1].
+
+sendemail.forbidSendmailVariables::
+ To avoid common misconfiguration mistakes, linkgit:git-send-email[1]
+ will abort with a warning if any configuration options for "sendmail"
+ exist. Set this variable to bypass the check.
diff --git a/Documentation/config/uploadpack.txt b/Documentation/config/uploadpack.txt
index ed1c835..b0d7612 100644
--- a/Documentation/config/uploadpack.txt
+++ b/Documentation/config/uploadpack.txt
@@ -57,6 +57,24 @@ uploadpack.allowFilter::
If this option is set, `upload-pack` will support partial
clone and partial fetch object filtering.
+uploadpackfilter.allow::
+ Provides a default value for unspecified object filters (see: the
+ below configuration variable).
+ Defaults to `true`.
+
+uploadpackfilter.<filter>.allow::
+ Explicitly allow or ban the object filter corresponding to
+ `<filter>`, where `<filter>` may be one of: `blob:none`,
+ `blob:limit`, `tree`, `sparse:oid`, or `combine`. If using
+ combined filters, both `combine` and all of the nested filter
+ kinds must be allowed. Defaults to `uploadpackfilter.allow`.
+
+uploadpackfilter.tree.maxDepth::
+ Only allow `--filter=tree:<n>` when `<n>` is no more than the value of
+ `uploadpackfilter.tree.maxDepth`. If set, this also implies
+ `uploadpackfilter.tree.allow=true`, unless this configuration
+ variable had already been set. Has no effect if unset.
+
uploadpack.allowRefInWant::
If this option is set, `upload-pack` will support the `ref-in-want`
feature of the protocol version 2 `fetch` command. This feature
diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt
index e8ed647..b10ff4c 100644
--- a/Documentation/diff-generate-patch.txt
+++ b/Documentation/diff-generate-patch.txt
@@ -10,7 +10,8 @@ linkgit:git-diff-tree[1], or
linkgit:git-diff-files[1]
with the `-p` option produces patch text.
You can customize the creation of patch text via the
-`GIT_EXTERNAL_DIFF` and the `GIT_DIFF_OPTS` environment variables.
+`GIT_EXTERNAL_DIFF` and the `GIT_DIFF_OPTS` environment variables
+(see linkgit:git[1]).
What the -p option produces is slightly different from the traditional
diff format:
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 7987d72..746b144 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -36,9 +36,9 @@ endif::git-format-patch[]
-U<n>::
--unified=<n>::
Generate diffs with <n> lines of context instead of
- the usual three. Implies `--patch`.
+ the usual three.
ifndef::git-format-patch[]
- Implies `-p`.
+ Implies `--patch`.
endif::git-format-patch[]
--output=<file>::
@@ -73,6 +73,11 @@ ifndef::git-format-patch[]
Synonym for `-p --raw`.
endif::git-format-patch[]
+ifdef::git-log[]
+-t::
+ Show the tree objects in the diff output.
+endif::git-log[]
+
--indent-heuristic::
Enable the heuristic that shifts diff hunk boundaries to make patches
easier to read. This is the default.
@@ -436,15 +441,20 @@ endif::git-format-patch[]
--binary::
In addition to `--full-index`, output a binary diff that
- can be applied with `git-apply`. Implies `--patch`.
+ can be applied with `git-apply`.
+ifndef::git-format-patch[]
+ Implies `--patch`.
+endif::git-format-patch[]
--abbrev[=<n>]::
Instead of showing the full 40-byte hexadecimal object
name in diff-raw format output and diff-tree header
- lines, show only a partial prefix. This is
- independent of the `--full-index` option above, which controls
- the diff-patch output format. Non default number of
- digits can be specified with `--abbrev=<n>`.
+ lines, show the shortest prefix that is at least '<n>'
+ hexdigits long that uniquely refers the object.
+ In diff-patch output format, `--full-index` takes higher
+ precedence, i.e. if `--full-index` is specified, full blob
+ names will be shown regardless of `--abbrev`.
+ Non default number of digits can be specified with `--abbrev=<n>`.
-B[<n>][/<m>]::
--break-rewrites[=[<n>][/<m>]]::
@@ -681,6 +691,11 @@ endif::git-format-patch[]
--ignore-blank-lines::
Ignore changes whose lines are all blank.
+-I<regex>::
+--ignore-matching-lines=<regex>::
+ Ignore changes whose all lines match <regex>. This option may
+ be specified more than once.
+
--inter-hunk-context=<lines>::
Show the context between diff hunks, up to the specified number
of lines, thereby fusing hunks that are close to each other.
@@ -689,7 +704,10 @@ endif::git-format-patch[]
-W::
--function-context::
- Show whole surrounding functions of changes.
+ Show whole function as context lines for each change.
+ The function names are determined in the same way as
+ `git diff` works out patch hunk headers (see 'Defining a
+ custom hunk-header' in linkgit:gitattributes[5]).
ifndef::git-format-patch[]
ifndef::git-log[]
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 6e2a160..2bf77b4 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -64,6 +64,15 @@ documented in linkgit:git-config[1].
--dry-run::
Show what would be done, without making any changes.
+ifndef::git-pull[]
+--[no-]write-fetch-head::
+ Write the list of remote refs fetched in the `FETCH_HEAD`
+ file directly under `$GIT_DIR`. This is the default.
+ Passing `--no-write-fetch-head` from the command line tells
+ Git not to write the file. Under `--dry-run` option, the
+ file is never written.
+endif::git-pull[]
+
-f::
--force::
When 'git fetch' is used with `<src>:<dst>` refspec it may
@@ -86,9 +95,11 @@ ifndef::git-pull[]
Allow several <repository> and <group> arguments to be
specified. No <refspec>s may be specified.
+--[no-]auto-maintenance::
--[no-]auto-gc::
- Run `git gc --auto` at the end to perform garbage collection
- if needed. This is enabled by default.
+ Run `git maintenance run --auto` at the end to perform automatic
+ repository maintenance if needed. (`--[no-]auto-gc` is a synonym.)
+ This is enabled by default.
--[no-]write-commit-graph::
Write a commit-graph after fetching. This overrides the config
@@ -186,7 +197,7 @@ ifndef::git-pull[]
endif::git-pull[]
--set-upstream::
- If the remote is fetched successfully, pull and add upstream
+ If the remote is fetched successfully, add upstream
(tracking) reference, used by argument-less
linkgit:git-pull[1] and other commands. For more information,
see `branch.<name>.merge` and `branch.<name>.remote` in
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 38c0852..06bc063 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -33,7 +33,7 @@ OPTIONS
-s::
--signoff::
- Add a `Signed-off-by:` line to the commit message, using
+ Add a `Signed-off-by` trailer to the commit message, using
the committer identity of yourself.
See the signoff option in linkgit:git-commit[1] for more information.
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index b9aa390..91d9a86 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -61,18 +61,18 @@ OPTIONS
file and detects errors. Turns off "apply".
--index::
- When `--check` is in effect, or when applying the patch
- (which is the default when none of the options that
- disables it is in effect), make sure the patch is
- applicable to what the current index file records. If
- the file to be patched in the working tree is not
- up to date, it is flagged as an error. This flag also
- causes the index file to be updated.
+ Apply the patch to both the index and the working tree (or
+ merely check that it would apply cleanly to both if `--check` is
+ in effect). Note that `--index` expects index entries and
+ working tree copies for relevant paths to be identical (their
+ contents and metadata such as file mode must match), and will
+ raise an error if they are not, even if the patch would apply
+ cleanly to both the index and the working tree in isolation.
--cached::
- Apply a patch without touching the working tree. Instead take the
- cached data, apply the patch, and store the result in the index
- without using the working tree. This implies `--index`.
+ Apply the patch to just the index, without touching the working
+ tree. If `--check` is in effect, merely check that it would
+ apply cleanly to the index entry.
--intent-to-add::
When applying the patch only to the working tree, mark new
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index cfa1e4e..9f81728 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -55,6 +55,12 @@ OPTIONS
--output=<file>::
Write the archive to <file> instead of stdout.
+--add-file=<file>::
+ Add a non-tracked file to the archive. Can be repeated to add
+ multiple files. The path of the file in the archive is built
+ by concatenating the value for `--prefix` (if any) and the
+ basename of <file>.
+
--worktree-attributes::
Look for attributes in .gitattributes files in the working tree
as well (see <<ATTRIBUTES>>).
diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt
index 3ba49e8..f3d9566 100644
--- a/Documentation/git-bisect-lk2009.txt
+++ b/Documentation/git-bisect-lk2009.txt
@@ -473,7 +473,7 @@ Z-Z
-------------
2) starting from the "good" ends of the graph, associate to each
-commit the number of ancestors it has plus one
+ commit the number of ancestors it has plus one
For example with the following graph where H is the "bad" commit and A
and D are some parents of some "good" commits:
@@ -514,7 +514,7 @@ D---E
-------------
4) the best bisection point is the commit with the highest associated
-number
+ number
So in the above example the best bisection point is commit C.
@@ -580,8 +580,8 @@ good or a bad commit does not give more or less information).
Let's also suppose that we have a cleaned up graph like one after step
1) in the bisection algorithm above. This means that we can measure
-the information we get in terms of number of commit we can remove from
-the graph..
+ the information we get in terms of number of commit we can remove
+ from the graph..
And let's take a commit X in the graph.
@@ -689,18 +689,18 @@ roughly the following steps:
6) sort the commit by decreasing associated value
7) if the first commit has not been skipped, we can return it and stop
-here
+ here
8) otherwise filter out all the skipped commits in the sorted list
9) use a pseudo random number generator (PRNG) to generate a random
-number between 0 and 1
+ number between 0 and 1
10) multiply this random number with its square root to bias it toward
-0
+ 0
11) multiply the result by the number of commits in the filtered list
-to get an index into this list
+ to get an index into this list
12) return the commit at the computed index
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 7586c5a..fbb39fb 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -16,8 +16,8 @@ DESCRIPTION
The command takes various subcommands, and different options depending
on the subcommand:
- git bisect start [--term-{old,good}=<term> --term-{new,bad}=<term>]
- [--no-checkout] [<bad> [<good>...]] [--] [<paths>...]
+ git bisect start [--term-{new,bad}=<term> --term-{old,good}=<term>]
+ [--no-checkout] [--first-parent] [<bad> [<good>...]] [--] [<paths>...]
git bisect (bad|new|<term-new>) [<rev>]
git bisect (good|old|<term-old>) [<rev>...]
git bisect terms [--term-good | --term-bad]
@@ -365,6 +365,17 @@ does not require a checked out tree.
+
If the repository is bare, `--no-checkout` is assumed.
+--first-parent::
++
+Follow only the first parent commit upon seeing a merge commit.
++
+In detecting regressions introduced through the merging of a branch, the merge
+commit will be identified as introduction of the bug and its ancestors will be
+ignored.
++
+This option is particularly useful in avoiding false positives when a merged
+branch contained broken or non-buildable commits, but the merge itself was OK.
+
EXAMPLES
--------
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 7e81541..34b496d 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -87,7 +87,9 @@ include::blame-options.txt[]
--abbrev=<n>::
Instead of using the default 7+1 hexadecimal digits as the
- abbreviated object name, use <n>+1 digits. Note that 1 column
+ abbreviated object name, use <m>+1 digits, where <m> is at
+ least <n> but ensures the commit object names are unique.
+ Note that 1 column
is used for a caret to mark the boundary commit.
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 03c0824..adaa178 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -9,9 +9,9 @@ SYNOPSIS
--------
[verse]
'git branch' [--color[=<when>] | --no-color] [--show-current]
- [-v [--abbrev=<length> | --no-abbrev]]
+ [-v [--abbrev=<n> | --no-abbrev]]
[--column[=<options>] | --no-column] [--sort=<key>]
- [(--merged | --no-merged) [<commit>]]
+ [--merged [<commit>]] [--no-merged [<commit>]]
[--contains [<commit>]] [--no-contains [<commit>]]
[--points-at <object>] [--format=<format>]
[(-r | --remotes) | (-a | --all)]
@@ -194,8 +194,10 @@ This option is only applicable in non-verbose mode.
Be more quiet when creating or deleting a branch, suppressing
non-error messages.
---abbrev=<length>::
- Alter the sha1's minimum display length in the output listing.
+--abbrev=<n>::
+ In the verbose listing that show the commit object name,
+ show the shortest prefix that is at least '<n>' hexdigits
+ long that uniquely refers the object.
The default value is 7 and can be overridden by the `core.abbrev`
config option.
@@ -252,13 +254,11 @@ start-point is either a local or remote-tracking branch.
--merged [<commit>]::
Only list branches whose tips are reachable from the
- specified commit (HEAD if not specified). Implies `--list`,
- incompatible with `--no-merged`.
+ specified commit (HEAD if not specified). Implies `--list`.
--no-merged [<commit>]::
Only list branches whose tips are not reachable from the
- specified commit (HEAD if not specified). Implies `--list`,
- incompatible with `--merged`.
+ specified commit (HEAD if not specified). Implies `--list`.
<branchname>::
The name of the branch to create or delete.
@@ -370,6 +370,8 @@ serve four related but different purposes:
- `--no-merged` is used to find branches which are candidates for merging
into HEAD, since those branches are not fully contained by HEAD.
+include::ref-reachability-filters.txt[]
+
SEE ALSO
--------
linkgit:git-check-ref-format[1],
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index d34b096..53804ca 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -9,7 +9,8 @@ git-bundle - Move objects and refs by archive
SYNOPSIS
--------
[verse]
-'git bundle' create [-q | --quiet | --progress | --all-progress] [--all-progress-implied] <file> <git-rev-list-args>
+'git bundle' create [-q | --quiet | --progress | --all-progress] [--all-progress-implied]
+ [--version=<version>] <file> <git-rev-list-args>
'git bundle' verify [-q | --quiet] <file>
'git bundle' list-heads <file> [<refname>...]
'git bundle' unbundle <file> [<refname>...]
@@ -102,6 +103,12 @@ unbundle <file>::
is activated. Unlike --all-progress this flag doesn't actually
force any progress display by itself.
+--version=<version>::
+ Specify the bundle version. Version 2 is the older format and can only be
+ used with SHA-1 repositories; the newer version 3 contains capabilities that
+ permit extensions. The default is the oldest supported format, based on the
+ hash algorithm in use.
+
-q::
--quiet::
This flag makes the command not to report its progress
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 5b697ee..b1a6fe4 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -192,12 +192,16 @@ branches from there if `<branch>` is ambiguous but exists on the
'origin' remote. See also `checkout.defaultRemote` in
linkgit:git-config[1].
+
-Use `--no-guess` to disable this.
+`--guess` is the default behavior. Use `--no-guess` to disable it.
++
+The default behavior can be set via the `checkout.guess` configuration
+variable.
-l::
Create the new branch's reflog; see linkgit:git-branch[1] for
details.
+-d::
--detach::
Rather than checking out a branch to work on it, check out a
commit for inspection and discardable experiments.
@@ -350,6 +354,10 @@ leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
<tree-ish>::
Tree to checkout from (when paths are given). If not specified,
the index will be used.
++
+As a special case, you may use `"A...B"` as a shortcut for the
+merge base of `A` and `B` if there is exactly one merge base. You can
+leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
\--::
Do not interpret any more arguments as options.
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 75feeef..5d75031 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -104,7 +104,7 @@ effect to your index in a row.
-s::
--signoff::
- Add Signed-off-by line at the end of the commit message.
+ Add a `Signed-off-by` trailer at the end of the commit message.
See the signoff option in linkgit:git-commit[1] for more information.
-S[<keyid>]::
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index c898310..876aedc 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -78,9 +78,9 @@ repository using this option and then delete branches (or use any
other Git command that makes any existing commit unreferenced) in the
source repository, some objects may become unreferenced (or dangling).
These objects may be removed by normal Git operations (such as `git commit`)
-which automatically call `git gc --auto`. (See linkgit:git-gc[1].)
-If these objects are removed and were referenced by the cloned repository,
-then the cloned repository will become corrupt.
+which automatically call `git maintenance run --auto`. (See
+linkgit:git-maintenance[1].) If these objects are removed and were referenced
+by the cloned repository, then the cloned repository will become corrupt.
+
Note that running `git repack` without the `--local` option in a repository
cloned with `--shared` will copy objects from the source repository into a pack
@@ -183,8 +183,9 @@ objects from the source repository into a pack in the cloned repository.
-o <name>::
--origin <name>::
- Instead of using the remote name `origin` to keep track
- of the upstream repository, use `<name>`.
+ Instead of using the remote name `origin` to keep track of the upstream
+ repository, use `<name>`. Overrides `clone.defaultRemoteName` from the
+ config.
-b <name>::
--branch <name>::
diff --git a/Documentation/git-commit-graph.txt b/Documentation/git-commit-graph.txt
index 8ca1764..e1f48c9 100644
--- a/Documentation/git-commit-graph.txt
+++ b/Documentation/git-commit-graph.txt
@@ -39,7 +39,9 @@ COMMANDS
--------
'write'::
-Write a commit-graph file based on the commits found in packfiles.
+Write a commit-graph file based on the commits found in packfiles. If
+the config option `core.commitGraph` is disabled, then this command will
+output a warning, then return success without writing a commit-graph file.
+
With the `--stdin-packs` option, generate the new commit graph by
walking objects only in the specified pack-indexes. (Cannot be combined
@@ -62,7 +64,17 @@ existing commit-graph file.
With the `--changed-paths` option, compute and write information about the
paths changed between a commit and its first parent. This operation can
take a while on large repositories. It provides significant performance gains
-for getting history of a directory or a file with `git log -- <path>`.
+for getting history of a directory or a file with `git log -- <path>`. If
+this option is given, future commit-graph writes will automatically assume
+that this option was intended. Use `--no-changed-paths` to stop storing this
+data.
++
+With the `--max-new-filters=<n>` option, generate at most `n` new Bloom
+filters (if `--changed-paths` is specified). If `n` is `-1`, no limit is
+enforced. Only commits present in the new layer count against this
+limit. To retroactively compute Bloom filters over earlier layers, it is
+advised to use `--split=replace`. Overrides the `commitGraph.maxNewFilters`
+configuration.
+
With the `--split[=<strategy>]` option, write the commit-graph as a
chain of multiple commit-graph files stored in
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index a3baea3..17150fa 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -59,6 +59,7 @@ commit by giving the same set of parameters (options and paths).
If you make a commit and then find a mistake immediately after
that, you can recover from it with 'git reset'.
+:git-commit: 1
OPTIONS
-------
@@ -163,14 +164,7 @@ The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.
message, the commit is aborted. This has no effect when a message
is given by other means, e.g. with the `-m` or `-F` options.
--s::
---signoff::
- Add Signed-off-by line by the committer at the end of the commit
- log message. The meaning of a signoff depends on the project,
- but it typically certifies that committer has
- the rights to submit this work under the same license and
- agrees to a Developer Certificate of Origin
- (see http://developercertificate.org/ for more information).
+include::signoff-option.txt[]
-n::
--no-verify::
diff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt
index f4bd815..27acb31 100644
--- a/Documentation/git-diff-index.txt
+++ b/Documentation/git-diff-index.txt
@@ -9,7 +9,7 @@ git-diff-index - Compare a tree to the working tree or index
SYNOPSIS
--------
[verse]
-'git diff-index' [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
+'git diff-index' [-m] [--cached] [--merge-base] [<common diff options>] <tree-ish> [<path>...]
DESCRIPTION
-----------
@@ -27,7 +27,12 @@ include::diff-options.txt[]
The id of a tree object to diff against.
--cached::
- do not consider the on-disk file at all
+ Do not consider the on-disk file at all.
+
+--merge-base::
+ Instead of comparing <tree-ish> directly, use the merge base
+ between <tree-ish> and HEAD instead. <tree-ish> must be a
+ commit.
-m::
By default, files recorded in the index but not checked
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 5c8a2a5..2fc24c5 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
- [-t] [-r] [-c | --cc] [--combined-all-paths] [--root]
+ [-t] [-r] [-c | --cc] [--combined-all-paths] [--root] [--merge-base]
[<common diff options>] <tree-ish> [<tree-ish>] [<path>...]
DESCRIPTION
@@ -43,6 +43,11 @@ include::diff-options.txt[]
When `--root` is specified the initial commit will be shown as a big
creation event. This is equivalent to a diff against the NULL tree.
+--merge-base::
+ Instead of comparing the <tree-ish>s directly, use the merge
+ base between the two <tree-ish>s as the "before" side. There
+ must be two <tree-ish>s given and they must both be commits.
+
--stdin::
When `--stdin` is specified, the command does not take
<tree-ish> arguments from the command line. Instead, it
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 727f24d..7f4c8a8 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -10,8 +10,8 @@ SYNOPSIS
--------
[verse]
'git diff' [<options>] [<commit>] [--] [<path>...]
-'git diff' [<options>] --cached [<commit>] [--] [<path>...]
-'git diff' [<options>] <commit> [<commit>...] <commit> [--] [<path>...]
+'git diff' [<options>] --cached [--merge-base] [<commit>] [--] [<path>...]
+'git diff' [<options>] [--merge-base] <commit> [<commit>...] <commit> [--] [<path>...]
'git diff' [<options>] <commit>...<commit> [--] [<path>...]
'git diff' [<options>] <blob> <blob>
'git diff' [<options>] --no-index [--] <path> <path>
@@ -40,7 +40,7 @@ files on disk.
or when running the command outside a working tree
controlled by Git. This form implies `--exit-code`.
-'git diff' [<options>] --cached [<commit>] [--] [<path>...]::
+'git diff' [<options>] --cached [--merge-base] [<commit>] [--] [<path>...]::
This form is to view the changes you staged for the next
commit relative to the named <commit>. Typically you
@@ -49,6 +49,10 @@ files on disk.
If HEAD does not exist (e.g. unborn branches) and
<commit> is not given, it shows all staged changes.
--staged is a synonym of --cached.
++
+If --merge-base is given, instead of using <commit>, use the merge base
+of <commit> and HEAD. `git diff --merge-base A` is equivalent to
+`git diff $(git merge-base A HEAD)`.
'git diff' [<options>] <commit> [--] [<path>...]::
@@ -58,23 +62,27 @@ files on disk.
branch name to compare with the tip of a different
branch.
-'git diff' [<options>] <commit> <commit> [--] [<path>...]::
+'git diff' [<options>] [--merge-base] <commit> <commit> [--] [<path>...]::
This is to view the changes between two arbitrary
<commit>.
++
+If --merge-base is given, use the merge base of the two commits for the
+"before" side. `git diff --merge-base A B` is equivalent to
+`git diff $(git merge-base A B) B`.
'git diff' [<options>] <commit> <commit>... <commit> [--] [<path>...]::
This form is to view the results of a merge commit. The first
listed <commit> must be the merge itself; the remaining two or
more commits should be its parents. A convenient way to produce
- the desired set of revisions is to use the {caret}@ suffix.
+ the desired set of revisions is to use the `^@` suffix.
For instance, if `master` names a merge commit, `git diff master
master^@` gives the same combined diff as `git show master`.
'git diff' [<options>] <commit>..<commit> [--] [<path>...]::
- This is synonymous to the earlier form (without the "..") for
+ This is synonymous to the earlier form (without the `..`) for
viewing the changes between two arbitrary <commit>. If <commit> on
one side is omitted, it will have the same effect as
using HEAD instead.
@@ -83,20 +91,20 @@ files on disk.
This form is to view the changes on the branch containing
and up to the second <commit>, starting at a common ancestor
- of both <commit>. "git diff A\...B" is equivalent to
- "git diff $(git merge-base A B) B". You can omit any one
+ of both <commit>. `git diff A...B` is equivalent to
+ `git diff $(git merge-base A B) B`. You can omit any one
of <commit>, which has the same effect as using HEAD instead.
Just in case you are doing something exotic, it should be
noted that all of the <commit> in the above description, except
-in the last two forms that use ".." notations, can be any
-<tree>.
+in the `--merge-base` case and in the last two forms that use `..`
+notations, can be any <tree>.
For a more complete list of ways to spell <commit>, see
"SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
However, "diff" is about comparing two _endpoints_, not ranges,
-and the range notations ("<commit>..<commit>" and
-"<commit>\...<commit>") do not mean a range as defined in the
+and the range notations (`<commit>..<commit>` and
+`<commit>...<commit>`) do not mean a range as defined in the
"SPECIFYING RANGES" section in linkgit:gitrevisions[7].
'git diff' [<options>] <blob> <blob>::
@@ -144,9 +152,9 @@ $ git diff HEAD <3>
+
<1> Changes in the working tree not yet staged for the next commit.
<2> Changes between the index and your last commit; what you
- would be committing if you run "git commit" without "-a" option.
+ would be committing if you run `git commit` without `-a` option.
<3> Changes in the working tree since your last commit; what you
- would be committing if you run "git commit -a"
+ would be committing if you run `git commit -a`
Comparing with arbitrary commits::
+
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 7d9aad2..39cfa05 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -814,7 +814,7 @@ may have uses for this information
'original-oid' SP <object-identifier> LF
....
-where `<object-identifer>` is any string not containing LF.
+where `<object-identifier>` is any string not containing LF.
`tag`
~~~~~
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 45b6d8e..9067c20 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -48,6 +48,10 @@ include::fetch-options.txt[]
include::pull-fetch-param.txt[]
+--stdin::
+ Read refspecs, one per line, from stdin in addition to those provided
+ as arguments. The "tag <name>" format is not supported.
+
include::urls-remotes.txt[]
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 40ba4aa..62e482a 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -532,7 +532,7 @@ The https://github.com/newren/git-filter-repo/[git filter-repo] tool is
an alternative to git-filter-branch which does not suffer from these
performance problems or the safety problems (mentioned below). For those
with existing tooling which relies upon git-filter-branch, 'git
-repo-filter' also provides
+filter-repo' also provides
https://github.com/newren/git-filter-repo/blob/master/contrib/filter-repo-demos/filter-lamely[filter-lamely],
a drop-in git-filter-branch replacement (with a few caveats). While
filter-lamely suffers from all the same safety issues as
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index 6dcd39f..2962f85 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl]
[(--sort=<key>)...] [--format=<format>] [<pattern>...]
[--points-at=<object>]
- (--merged[=<object>] | --no-merged[=<object>])
+ [--merged[=<object>]] [--no-merged[=<object>]]
[--contains[=<object>]] [--no-contains[=<object>]]
DESCRIPTION
@@ -76,13 +76,11 @@ OPTIONS
--merged[=<object>]::
Only list refs whose tips are reachable from the
- specified commit (HEAD if not specified),
- incompatible with `--no-merged`.
+ specified commit (HEAD if not specified).
--no-merged[=<object>]::
Only list refs whose tips are not reachable from the
- specified commit (HEAD if not specified),
- incompatible with `--merged`.
+ specified commit (HEAD if not specified).
--contains[=<object>]::
Only list refs which contain the specified commit (HEAD if not
@@ -222,6 +220,8 @@ worktreepath::
In addition to the above, for commit and tag objects, the header
field names (`tree`, `parent`, `object`, `type`, and `tag`) can
be used to specify the value in the header field.
+Fields `tree` and `parent` can also be used with modifier `:short` and
+`:short=<length>` just like `objectname`.
For commit and tag objects, the special `creatordate` and `creator`
fields will correspond to the appropriate date or name-email-date tuple
@@ -230,14 +230,35 @@ These are intended for working on a mix of annotated and lightweight tags.
Fields that have name-email-date tuple as its value (`author`,
`committer`, and `tagger`) can be suffixed with `name`, `email`,
-and `date` to extract the named component.
-
-The complete message in a commit and tag object is `contents`.
-Its first line is `contents:subject`, where subject is the concatenation
-of all lines of the commit message up to the first blank line. The next
-line is `contents:body`, where body is all of the lines after the first
-blank line. The optional GPG signature is `contents:signature`. The
-first `N` lines of the message is obtained using `contents:lines=N`.
+and `date` to extract the named component. For email fields (`authoremail`,
+`committeremail` and `taggeremail`), `:trim` can be appended to get the email
+without angle brackets, and `:localpart` to get the part before the `@` symbol
+out of the trimmed email.
+
+The message in a commit or a tag object is `contents`, from which
+`contents:<part>` can be used to extract various parts out of:
+
+contents:size::
+ The size in bytes of the commit or tag message.
+
+contents:subject::
+ The first paragraph of the message, which typically is a
+ single line, is taken as the "subject" of the commit or the
+ tag message.
+ Instead of `contents:subject`, field `subject` can also be used to
+ obtain same results. `:sanitize` can be appended to `subject` for
+ subject line suitable for filename.
+
+contents:body::
+ The remainder of the commit or the tag message that follows
+ the "subject".
+
+contents:signature::
+ The optional GPG signature of the tag.
+
+contents:lines=N::
+ The first `N` lines of the message.
+
Additionally, the trailers as interpreted by linkgit:git-interpret-trailers[1]
are obtained as `trailers` (or by using the historical alias
`contents:trailers`). Non-trailer lines from the trailer block can be omitted
@@ -385,6 +406,11 @@ Note also that multiple copies of an object may be present in the object
database; in this case, it is undefined which copy's size or delta base
will be reported.
+NOTES
+-----
+
+include::ref-reachability-filters.txt[]
+
SEE ALSO
--------
linkgit:git-show-ref[1]
diff --git a/Documentation/git-for-each-repo.txt b/Documentation/git-for-each-repo.txt
new file mode 100644
index 0000000..94bd19d
--- /dev/null
+++ b/Documentation/git-for-each-repo.txt
@@ -0,0 +1,59 @@
+git-for-each-repo(1)
+====================
+
+NAME
+----
+git-for-each-repo - Run a Git command on a list of repositories
+
+
+SYNOPSIS
+--------
+[verse]
+'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.
+
+
+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 linkgit:git[1] suite
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 0f81d04..bf1bb40 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -119,7 +119,7 @@ include::diff-options.txt[]
-s::
--signoff::
- Add `Signed-off-by:` line to the commit message, using
+ Add a `Signed-off-by` trailer to the commit message, using
the committer identity of yourself.
See the signoff option in linkgit:git-commit[1] for more information.
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index a7f9bc9..4e0ba82 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -209,7 +209,7 @@ providing this option will cause it to die.
Use \0 as the delimiter for pathnames in the output, and print
them verbatim. Without this option, pathnames with "unusual"
characters are quoted as explained for the configuration
- variable core.quotePath (see git-config(1)).
+ variable core.quotePath (see linkgit:git-config[1]).
-o::
--only-matching::
@@ -241,7 +241,7 @@ providing this option will cause it to die.
--show-function::
Show the preceding line that contains the function name of
the match, unless the matching line is a function name itself.
- The name is determined in the same way as 'git diff' works out
+ The name is determined in the same way as `git diff` works out
patch hunk headers (see 'Defining a custom hunk-header' in
linkgit:gitattributes[5]).
@@ -266,7 +266,9 @@ providing this option will cause it to die.
Show the surrounding text from the previous line containing a
function name up to the one before the next function name,
effectively showing the whole function in which the match was
- found.
+ found. The function names are determined in the same way as
+ `git diff` works out patch hunk headers (see 'Defining a
+ custom hunk-header' in linkgit:gitattributes[5]).
--threads <num>::
Number of grep worker threads to use.
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index f71db0d..44fe886 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -8,7 +8,7 @@ git-help - Display help information about Git
SYNOPSIS
--------
[verse]
-'git help' [-a|--all [--[no-]verbose]] [-g|--guide]
+'git help' [-a|--all [--[no-]verbose]] [-g|--guides]
[-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE]
DESCRIPTION
@@ -21,8 +21,8 @@ on the standard output.
If the option `--all` or `-a` is given, all available commands are
printed on the standard output.
-If the option `--guide` or `-g` is given, a list of the useful
-Git guides is also printed on the standard output.
+If the option `--guides` or `-g` is given, a list of the
+Git concept guides is also printed on the standard output.
If a command, or a guide, is given, a manual page for that command or
guide is brought up. The 'man' program is used by default for this
@@ -58,7 +58,7 @@ OPTIONS
-g::
--guides::
- Prints a list of useful guides on the standard output. This
+ Prints a list of the Git concept guides on the standard output. This
option overrides any given command or guide name.
-i::
diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
index 65b53fc..63cf498 100644
--- a/Documentation/git-imap-send.txt
+++ b/Documentation/git-imap-send.txt
@@ -51,17 +51,13 @@ OPTIONS
CONFIGURATION
-------------
-To use the tool, imap.folder and either imap.tunnel or imap.host must be set
+To use the tool, `imap.folder` and either `imap.tunnel` or `imap.host` must be set
to appropriate values.
-Variables
-~~~~~~~~~
-
include::config/imap.txt[]
-Examples
-~~~~~~~~
-
+EXAMPLES
+--------
Using tunnel mode:
..........................
@@ -89,14 +85,18 @@ Using direct mode with SSL:
user = bob
pass = p4ssw0rd
port = 123
- sslverify = false
+ ; sslVerify = false
.........................
-EXAMPLES
---------
-To submit patches using GMail's IMAP interface, first, edit your ~/.gitconfig
-to specify your account settings:
+[NOTE]
+You may want to use `sslVerify=false`
+while troubleshooting, if you suspect that the reason you are
+having trouble connecting is because the certificate you use at
+the private server `example.com` you are trying to set up (or
+have set up) may not be verified correctly.
+
+Using Gmail's IMAP interface:
---------
[imap]
@@ -104,17 +104,21 @@ to specify your account settings:
host = imaps://imap.gmail.com
user = user@gmail.com
port = 993
- sslverify = false
---------
-You might need to instead use: folder = "[Google Mail]/Drafts" if you get an error
+[NOTE]
+You might need to instead use: `folder = "[Google Mail]/Drafts"` if you get an error
that the "Folder doesn't exist".
+[NOTE]
+If your Gmail account is set to another language than English, the name of the "Drafts"
+folder will be localized.
+
Once the commits are ready to be sent, run the following command:
$ git format-patch --cover-letter -M --stdout origin/master | git imap-send
-Just make sure to disable line wrapping in the email client (GMail's web
+Just make sure to disable line wrapping in the email client (Gmail's web
interface will wrap lines no matter what, so you need to use a real
IMAP client).
diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt
index 9316d9a..af0c262 100644
--- a/Documentation/git-index-pack.txt
+++ b/Documentation/git-index-pack.txt
@@ -100,12 +100,14 @@ OPTIONS
value is set or outside a repository.
+
This option cannot be used with --stdin.
++
+include::object-format-disclaimer.txt[]
NOTES
-----
-Once the index has been created, the list of object names is sorted
-and the SHA-1 hash of that list is printed to stdout. If --stdin was
+Once the index has been created, the hash that goes into the name of
+the pack/idx file is printed to stdout. If --stdin was
also used then this is prefixed by either "pack\t", or "keep\t" if a
new .keep file was successfully created. This is useful to remove a
.keep file used as a lock to prevent the race with 'git repack'
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index ddfe265..59ecda6 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -53,6 +53,8 @@ current working directory.
Specify the given object format (hash algorithm) for the repository. The valid
values are 'sha1' and (if enabled) 'sha256'. 'sha1' is the default.
++
+include::object-format-disclaimer.txt[]
--template=<template_directory>::
@@ -68,7 +70,7 @@ repository.
+
If this is reinitialization, the repository will be moved to the specified path.
--b <branch-name::
+-b <branch-name>::
--initial-branch=<branch-name>::
Use the specified name for the initial branch in the newly created repository.
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 20e6d21..dd189a3 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -15,9 +15,12 @@ DESCRIPTION
-----------
Shows the commit logs.
-The command takes options applicable to the `git rev-list`
+:git-log: 1
+include::rev-list-description.txt[]
+
+The command takes options applicable to the linkgit:git-rev-list[1]
command to control what is shown and how, and options applicable to
-the `git diff-*` commands to control how the changes
+the linkgit:git-diff[1] command to control how the changes
each commit introduces are shown.
@@ -74,20 +77,7 @@ produced by `--stat`, etc.
Intended to speed up tools that read log messages from `git log`
output by allowing them to allocate space in advance.
--L <start>,<end>:<file>::
--L :<funcname>:<file>::
- Trace the evolution of the line range given by "<start>,<end>"
- (or the function name regex <funcname>) within the <file>. You may
- not give any pathspec limiters. This is currently limited to
- a walk starting from a single revision, i.e., you may only
- give zero or one positive revision arguments, and
- <start> and <end> (or <funcname>) must exist in the starting revision.
- You can specify this option more than once. Implies `--patch`.
- Patch output can be suppressed using `--no-patch`, but other diff formats
- (namely `--raw`, `--numstat`, `--shortstat`, `--dirstat`, `--summary`,
- `--name-only`, `--name-status`, `--check`) are not currently implemented.
-+
-include::line-range-format.txt[]
+include::line-range-options.txt[]
<revision range>::
Show only commits in the specified revision range. When no
@@ -111,8 +101,51 @@ include::rev-list-options.txt[]
include::pretty-formats.txt[]
-COMMON DIFF OPTIONS
--------------------
+DIFF FORMATTING
+---------------
+
+By default, `git log` does not generate any diff output. The options
+below can be used to show the changes made by each commit.
+
+Note that unless one of `-c`, `--cc`, or `-m` is given, merge commits
+will never show a diff, even if a diff format like `--patch` is
+selected, nor will they match search options like `-S`. The exception is
+when `--first-parent` is in use, in which merges are treated like normal
+single-parent commits (this can be overridden by providing a
+combined-diff option or with `--no-diff-merges`).
+
+-c::
+ With this option, diff output for a merge commit
+ shows the differences from each of the parents to the merge result
+ simultaneously instead of showing pairwise diff between a parent
+ and the result one at a time. Furthermore, it lists only files
+ which were modified from all parents.
+
+--cc::
+ This flag implies the `-c` option and further compresses the
+ patch output by omitting uninteresting hunks whose contents in
+ the parents have only two variants and the merge result picks
+ one of them without modification.
+
+--combined-all-paths::
+ This flag causes combined diffs (used for merge commits) to
+ list the name of the file from all parents. It thus only has
+ effect when -c or --cc are specified, and is likely only
+ useful if filename changes are detected (i.e. when either
+ rename or copy detection have been requested).
+
+-m::
+ This flag makes the merge commits show the full diff like
+ regular commits; for each merge parent, a separate log entry
+ and diff is generated. An exception is that only diff against
+ the first parent is shown when `--first-parent` option is given;
+ in that case, the output represents the changes the merge
+ brought _into_ the then-current branch.
+
+--diff-merges=off::
+--no-diff-merges::
+ Disable output of diffs for merge commits (default). Useful to
+ override `-m`, `-c`, or `--cc`.
:git-log: 1
include::diff-options.txt[]
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 3cb2ebb..cbcf526 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -19,7 +19,7 @@ SYNOPSIS
[--exclude-standard]
[--error-unmatch] [--with-tree=<tree-ish>]
[--full-name] [--recurse-submodules]
- [--abbrev] [--] [<file>...]
+ [--abbrev[=<n>]] [--] [<file>...]
DESCRIPTION
-----------
@@ -153,7 +153,8 @@ a space) at the start of each line:
--abbrev[=<n>]::
Instead of showing the full 40-byte hexadecimal object
- lines, show only a partial prefix.
+ lines, show the shortest prefix that is at least '<n>'
+ hexdigits long that uniquely refers the object.
Non default number of digits can be specified with --abbrev=<n>.
--debug::
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index a751571..db02d6d 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -62,7 +62,8 @@ OPTIONS
--abbrev[=<n>]::
Instead of showing the full 40-byte hexadecimal object
- lines, show only a partial prefix.
+ lines, show the shortest prefix that is at least '<n>'
+ hexdigits long that uniquely refers the object.
Non default number of digits can be specified with --abbrev=<n>.
--full-name::
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 3bbc731..7a6aed0 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -72,10 +72,9 @@ conversion, even with this flag.
is useful in order to associate commits with mailing list discussions.
--scissors::
- Remove everything in body before a scissors line. A line that
- mainly consists of scissors (either ">8" or "8<") and perforation
- (dash "-") marks is called a scissors line, and is used to request
- the reader to cut the message at that line. If such a line
+ Remove everything in body before a scissors line (e.g. "-- >8 --").
+ The line represents scissors and perforation marks, and is used to
+ request the reader to cut the message at that line. If that line
appears in the body of the message before the patch, everything
before it (including the scissors line itself) is ignored when
this option is used.
diff --git a/Documentation/git-maintenance.txt b/Documentation/git-maintenance.txt
new file mode 100644
index 0000000..6fec1eb
--- /dev/null
+++ b/Documentation/git-maintenance.txt
@@ -0,0 +1,224 @@
+git-maintenance(1)
+==================
+
+NAME
+----
+git-maintenance - Run tasks to optimize Git repository data
+
+
+SYNOPSIS
+--------
+[verse]
+'git maintenance' run [<options>]
+
+
+DESCRIPTION
+-----------
+Run tasks to optimize Git repository data, speeding up other Git commands
+and reducing storage requirements for the repository.
+
+Git commands that add repository data, such as `git add` or `git fetch`,
+are optimized for a responsive user experience. These commands do not take
+time to optimize the Git data, since such optimizations scale with the full
+size of the repository while these user commands each perform a relatively
+small action.
+
+The `git maintenance` command provides flexibility for how to optimize the
+Git repository.
+
+SUBCOMMANDS
+-----------
+
+register::
+ Initialize Git config values so any scheduled maintenance will
+ start running on this repository. This adds the repository to the
+ `maintenance.repo` config variable in the current user's global
+ config and enables some recommended configuration values for
+ `maintenance.<task>.schedule`. The tasks that are enabled are safe
+ for running in the background without disrupting foreground
+ processes.
++
+The `register` subcomand will also set the `maintenance.strategy` config
+value to `incremental`, if this value is not previously set. The
+`incremental` strategy uses the following schedule for each maintenance
+task:
++
+--
+* `gc`: disabled.
+* `commit-graph`: hourly.
+* `prefetch`: hourly.
+* `loose-objects`: daily.
+* `incremental-repack`: daily.
+--
++
+`git maintenance register` will also disable foreground maintenance by
+setting `maintenance.auto = false` in the current repository. This config
+setting will remain after a `git maintenance unregister` command.
+
+run::
+ Run one or more maintenance tasks. If one or more `--task` options
+ are specified, then those tasks are run in that order. Otherwise,
+ the tasks are determined by which `maintenance.<task>.enabled`
+ config options are true. By default, only `maintenance.gc.enabled`
+ is true.
+
+start::
+ Start running maintenance on the current repository. This performs
+ the same config updates as the `register` subcommand, then updates
+ the background scheduler to run `git maintenance run --scheduled`
+ on an hourly basis.
+
+stop::
+ Halt the background maintenance schedule. The current repository
+ is not removed from the list of maintained repositories, in case
+ the background maintenance is restarted later.
+
+unregister::
+ Remove the current repository from background maintenance. This
+ only removes the repository from the configured list. It does not
+ stop the background maintenance processes from running.
+
+TASKS
+-----
+
+commit-graph::
+ The `commit-graph` job updates the `commit-graph` files incrementally,
+ then verifies that the written data is correct. The incremental
+ write is safe to run alongside concurrent Git processes since it
+ will not expire `.graph` files that were in the previous
+ `commit-graph-chain` file. They will be deleted by a later run based
+ on the expiration delay.
+
+prefetch::
+ The `prefetch` task updates the object directory with the latest
+ objects from all registered remotes. For each remote, a `git fetch`
+ command is run. The refmap is custom to avoid updating local or remote
+ branches (those in `refs/heads` or `refs/remotes`). Instead, the
+ remote refs are stored in `refs/prefetch/<remote>/`. Also, tags are
+ not updated.
++
+This is done to avoid disrupting the remote-tracking branches. The end users
+expect these refs to stay unmoved unless they initiate a fetch. With prefetch
+task, however, the objects necessary to complete a later real fetch would
+already be obtained, so the real fetch would go faster. In the ideal case,
+it will just become an update to bunch of remote-tracking branches without
+any object transfer.
+
+gc::
+ Clean up unnecessary files and optimize the local repository. "GC"
+ stands for "garbage collection," but this task performs many
+ smaller tasks. This task can be expensive for large repositories,
+ as it repacks all Git objects into a single pack-file. It can also
+ be disruptive in some situations, as it deletes stale data. See
+ linkgit:git-gc[1] for more details on garbage collection in Git.
+
+loose-objects::
+ The `loose-objects` job cleans up loose objects and places them into
+ pack-files. In order to prevent race conditions with concurrent Git
+ commands, it follows a two-step process. First, it deletes any loose
+ objects that already exist in a pack-file; concurrent Git processes
+ will examine the pack-file for the object data instead of the loose
+ object. Second, it creates a new pack-file (starting with "loose-")
+ containing a batch of loose objects. The batch size is limited to 50
+ thousand objects to prevent the job from taking too long on a
+ repository with many loose objects. The `gc` task writes unreachable
+ objects as loose objects to be cleaned up by a later step only if
+ they are not re-added to a pack-file; for this reason it is not
+ advisable to enable both the `loose-objects` and `gc` tasks at the
+ same time.
+
+incremental-repack::
+ The `incremental-repack` job repacks the object directory
+ using the `multi-pack-index` feature. In order to prevent race
+ conditions with concurrent Git commands, it follows a two-step
+ process. First, it calls `git multi-pack-index expire` to delete
+ pack-files unreferenced by the `multi-pack-index` file. Second, it
+ calls `git multi-pack-index repack` to select several small
+ pack-files and repack them into a bigger one, and then update the
+ `multi-pack-index` entries that refer to the small pack-files to
+ refer to the new pack-file. This prepares those small pack-files
+ for deletion upon the next run of `git multi-pack-index expire`.
+ The selection of the small pack-files is such that the expected
+ size of the big pack-file is at least the batch size; see the
+ `--batch-size` option for the `repack` subcommand in
+ linkgit:git-multi-pack-index[1]. The default batch-size is zero,
+ which is a special case that attempts to repack all pack-files
+ into a single pack-file.
+
+OPTIONS
+-------
+--auto::
+ When combined with the `run` subcommand, run maintenance tasks
+ only if certain thresholds are met. For example, the `gc` task
+ runs when the number of loose objects exceeds the number stored
+ in the `gc.auto` config setting, or when the number of pack-files
+ exceeds the `gc.autoPackLimit` config setting. Not compatible with
+ the `--schedule` option.
+
+--schedule::
+ When combined with the `run` subcommand, run maintenance tasks
+ only if certain time conditions are met, as specified by the
+ `maintenance.<task>.schedule` config value for each `<task>`.
+ This config value specifies a number of seconds since the last
+ time that task ran, according to the `maintenance.<task>.lastRun`
+ config value. The tasks that are tested are those provided by
+ the `--task=<task>` option(s) or those with
+ `maintenance.<task>.enabled` set to true.
+
+--quiet::
+ Do not report progress or other information over `stderr`.
+
+--task=<task>::
+ If this option is specified one or more times, then only run the
+ specified tasks in the specified order. If no `--task=<task>`
+ arguments are specified, then only the tasks with
+ `maintenance.<task>.enabled` configured as `true` are considered.
+ See the 'TASKS' section for the list of accepted `<task>` values.
+
+
+TROUBLESHOOTING
+---------------
+The `git maintenance` command is designed to simplify the repository
+maintenance patterns while minimizing user wait time during Git commands.
+A variety of configuration options are available to allow customizing this
+process. The default maintenance options focus on operations that complete
+quickly, even on large repositories.
+
+Users may find some cases where scheduled maintenance tasks do not run as
+frequently as intended. Each `git maintenance run` command takes a lock on
+the repository's object database, and this prevents other concurrent
+`git maintenance run` commands from running on the same repository. Without
+this safeguard, competing processes could leave the repository in an
+unpredictable state.
+
+The background maintenance schedule runs `git maintenance run` processes
+on an hourly basis. Each run executes the "hourly" tasks. At midnight,
+that process also executes the "daily" tasks. At midnight on the first day
+of the week, that process also executes the "weekly" tasks. A single
+process iterates over each registered repository, performing the scheduled
+tasks for that frequency. Depending on the number of registered
+repositories and their sizes, this process may take longer than an hour.
+In this case, multiple `git maintenance run` commands may run on the same
+repository at the same time, colliding on the object database lock. This
+results in one of the two tasks not running.
+
+If you find that some maintenance windows are taking longer than one hour
+to complete, then consider reducing the complexity of your maintenance
+tasks. For example, the `gc` task is much slower than the
+`incremental-repack` task. However, this comes at a cost of a slightly
+larger object database. Consider moving more expensive tasks to be run
+less frequently.
+
+Expert users may consider scheduling their own maintenance tasks using a
+different schedule than is available through `git maintenance start` and
+Git configuration options. These users should be aware of the object
+database lock and how concurrent `git maintenance run` commands behave.
+Further, the `git gc` command should not be combined with
+`git maintenance run` commands. `git gc` modifies the object database
+but does not take the lock in the same way as `git maintenance run`. If
+possible, use `git maintenance run --task=gc` instead of `git gc`.
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-multi-pack-index.txt b/Documentation/git-multi-pack-index.txt
index 0c66194..eb0caa0 100644
--- a/Documentation/git-multi-pack-index.txt
+++ b/Documentation/git-multi-pack-index.txt
@@ -51,11 +51,12 @@ repack::
multi-pack-index, then divide by the total number of objects in
the pack and multiply by the pack size. We select packs with
expected size below the batch size until the set of packs have
- total expected size at least the batch size. If the total size
- does not reach the batch size, then do nothing. If a new pack-
- file is created, rewrite the multi-pack-index to reference the
- new pack-file. A later run of 'git multi-pack-index expire' will
- delete the pack-files that were part of this batch.
+ total expected size at least the batch size, or all pack-files
+ are considered. If only one pack-file is selected, then do
+ nothing. If a new pack-file is created, rewrite the
+ multi-pack-index to reference the new pack-file. A later run of
+ 'git multi-pack-index expire' will delete the pack-files that
+ were part of this batch.
+
If `repack.packKeptObjects` is `false`, then any pack-files with an
associated `.keep` file will not be selected for the batch to repack.
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index ced2e82..0a42006 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -223,7 +223,7 @@ are taken from notes refs. A notes ref is usually a branch which
contains "files" whose paths are the object names for the objects
they describe, with some directory separators included for performance
reasons footnote:[Permitted pathnames have the form
-'ab'`/`'cd'`/`'ef'`/`'...'`/`'abcdef...': a sequence of directory
+'bf'`/`'fe'`/`'30'`/`'...'`/`'680d5a...': a sequence of directory
names of two hexadecimal digits each followed by a filename with the
rest of the object ID.].
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index dab9609..ec233ac 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -417,7 +417,7 @@ p4-post-changelist
~~~~~~~~~~~~~~~~~~
The `p4-post-changelist` hook is invoked after the submit has
-successfully occured in P4. It takes no parameters and is meant
+successfully occurred in P4. It takes no parameters and is meant
primarily for notification and cannot affect the outcome of the
git p4 submit action.
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index eaa2f2a..54d715e 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -270,15 +270,18 @@ So does `git bundle` (see linkgit:git-bundle[1]) when it creates a bundle.
This option specifies how missing objects are handled.
+
The form '--missing=error' requests that pack-objects stop with an error if
-a missing object is encountered. This is the default action.
+a missing object is encountered. If the repository is a partial clone, an
+attempt to fetch missing objects will be made before declaring them missing.
+This is the default action.
+
The form '--missing=allow-any' will allow object traversal to continue
-if a missing object is encountered. Missing objects will silently be
-omitted from the results.
+if a missing object is encountered. No fetch of a missing object will occur.
+Missing objects will silently be omitted from the results.
+
The form '--missing=allow-promisor' is like 'allow-any', but will only
allow object traversal to continue for EXPECTED promisor missing objects.
-Unexpected missing object will raise an error.
+No fetch of a missing object will occur. An unexpected missing object will
+raise an error.
--exclude-promisor-objects::
Omit objects that are known to be in the promisor remote. (This
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 3b80534..ab103c8 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-v | --verbose]
[-u | --set-upstream] [-o <string> | --push-option=<string>]
[--[no-]signed|--signed=(true|false|if-asked)]
- [--force-with-lease[=<refname>[:<expect>]]]
+ [--force-with-lease[=<refname>[:<expect>]] [--force-if-includes]]
[--no-verify] [<repository> [<refspec>...]]
DESCRIPTION
@@ -320,6 +320,14 @@ seen and are willing to overwrite, then rewrite history, and finally
force push changes to `master` if the remote version is still at
`base`, regardless of what your local `remotes/origin/master` has been
updated to in the background.
++
+Alternatively, specifying `--force-if-includes` as an ancillary option
+along with `--force-with-lease[=<refname>]` (i.e., without saying what
+exact commit the ref on the remote side must be pointing at, or which
+refs on the remote side are being protected) at the time of "push" will
+verify if updates from the remote-tracking refs that may have been
+implicitly updated in the background are integrated locally before
+allowing a forced update.
-f::
--force::
@@ -341,6 +349,22 @@ one branch, use a `+` in front of the refspec to push (e.g `git push
origin +master` to force a push to the `master` branch). See the
`<refspec>...` section above for details.
+--[no-]force-if-includes::
+ Force an update only if the tip of the remote-tracking ref
+ has been integrated locally.
++
+This option enables a check that verifies if the tip of the
+remote-tracking ref is reachable from one of the "reflog" entries of
+the local branch based in it for a rewrite. The check ensures that any
+updates from the remote have been incorporated locally by rejecting the
+forced update if that is not the case.
++
+If the option is passed without specifying `--force-with-lease`, or
+specified along with `--force-with-lease=<refname>:<expect>`, it is
+a "no-op".
++
+Specifying `--no-force-if-includes` disables this behavior.
+
--repo=<repository>::
This option is equivalent to the <repository> argument. If both
are specified, the command-line argument takes precedence.
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 374d248..a0487b5 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -204,6 +204,7 @@ CONFIGURATION
-------------
include::config/rebase.txt[]
+include::config/sequencer.txt[]
OPTIONS
-------
@@ -459,22 +460,43 @@ with `--keep-base` in order to drop those commits from your branch.
See also INCOMPATIBLE OPTIONS below.
--ignore-whitespace::
+ Ignore whitespace differences when trying to reconcile
+differences. Currently, each backend implements an approximation of
+this behavior:
++
+apply backend: When applying a patch, ignore changes in whitespace in
+context lines. Unfortunately, this means that if the "old" lines being
+replaced by the patch differ only in whitespace from the existing
+file, you will get a merge conflict instead of a successful patch
+application.
++
+merge backend: Treat lines with only whitespace changes as unchanged
+when merging. Unfortunately, this means that any patch hunks that were
+intended to modify whitespace and nothing else will be dropped, even
+if the other side had no changes that conflicted.
+
--whitespace=<option>::
- These flags are passed to the 'git apply' program
+ This flag is passed to the 'git apply' program
(see linkgit:git-apply[1]) that applies the patch.
Implies --apply.
+
See also INCOMPATIBLE OPTIONS below.
--committer-date-is-author-date::
+ Instead of using the current time as the committer date, use
+ the author date of the commit being rebased as the committer
+ date. This option implies `--force-rebase`.
+
--ignore-date::
- These flags are passed to 'git am' to easily change the dates
- of the rebased commits (see linkgit:git-am[1]).
+--reset-author-date::
+ Instead of using the author date of the original commit, use
+ the current time as the author date of the rebased commit. This
+ option implies `--force-rebase`.
+
See also INCOMPATIBLE OPTIONS below.
--signoff::
- Add a Signed-off-by: trailer to all the rebased commits. Note
+ Add a `Signed-off-by` trailer to all the rebased commits. Note
that if `--interactive` is given then only commits marked to be
picked, edited or reworded will have the trailer added.
+
@@ -607,9 +629,6 @@ INCOMPATIBLE OPTIONS
The following options:
* --apply
- * --committer-date-is-author-date
- * --ignore-date
- * --ignore-whitespace
* --whitespace
* -C
@@ -636,6 +655,9 @@ In addition, the following pairs of options are incompatible:
* --preserve-merges and --signoff
* --preserve-merges and --rebase-merges
* --preserve-merges and --empty=
+ * --preserve-merges and --ignore-whitespace
+ * --preserve-merges and --committer-date-is-author-date
+ * --preserve-merges and --ignore-date
* --keep-base and --onto
* --keep-base and --root
* --fork-point and --root
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 9659abb..31c29c9 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git remote' [-v | --verbose]
-'git remote add' [-t <branch>] [-m <master>] [-f] [--[no-]tags] [--mirror=<fetch|push>] <name> <url>
+'git remote add' [-t <branch>] [-m <master>] [-f] [--[no-]tags] [--mirror=(fetch|push)] <name> <url>
'git remote rename' <old> <new>
'git remote remove' <name>
'git remote set-head' <name> (-a | --auto | -d | --delete | <branch>)
@@ -35,7 +35,7 @@ OPTIONS
-v::
--verbose::
Be a little more verbose and show remote url after name.
- NOTE: This must be placed between `remote` and `subcommand`.
+ NOTE: This must be placed between `remote` and subcommand.
COMMANDS
@@ -46,7 +46,7 @@ subcommands are available to perform operations on the remotes.
'add'::
-Adds a remote named <name> for the repository at
+Add a remote named <name> for the repository at
<url>. The command `git fetch <name>` can then be used to create and
update remote-tracking branches <name>/<branch>.
+
@@ -109,13 +109,13 @@ With `-d` or `--delete`, the symbolic ref `refs/remotes/<name>/HEAD` is deleted.
+
With `-a` or `--auto`, the remote is queried to determine its `HEAD`, then the
symbolic-ref `refs/remotes/<name>/HEAD` is set to the same branch. e.g., if the remote
-`HEAD` is pointed at `next`, "`git remote set-head origin -a`" will set
+`HEAD` is pointed at `next`, `git remote set-head origin -a` will set
the symbolic-ref `refs/remotes/origin/HEAD` to `refs/remotes/origin/next`. This will
only work if `refs/remotes/origin/next` already exists; if not it must be
fetched first.
+
-Use `<branch>` to set the symbolic-ref `refs/remotes/<name>/HEAD` explicitly. e.g., "git
-remote set-head origin master" will set the symbolic-ref `refs/remotes/origin/HEAD` to
+Use `<branch>` to set the symbolic-ref `refs/remotes/<name>/HEAD` explicitly. e.g., `git
+remote set-head origin master` will set the symbolic-ref `refs/remotes/origin/HEAD` to
`refs/remotes/origin/master`. This will only work if
`refs/remotes/origin/master` already exists; if not it must be fetched first.
+
@@ -127,7 +127,7 @@ This can be used to track a subset of the available remote branches
after the initial setup for a remote.
+
The named branches will be interpreted as if specified with the
-`-t` option on the 'git remote add' command line.
+`-t` option on the `git remote add` command line.
+
With `--add`, instead of replacing the list of currently tracked
branches, adds to that list.
@@ -181,16 +181,16 @@ fetch --prune <name>`, except that no new references will be fetched.
See the PRUNING section of linkgit:git-fetch[1] for what it'll prune
depending on various configuration.
+
-With `--dry-run` option, report what branches will be pruned, but do not
+With `--dry-run` option, report what branches would be pruned, but do not
actually prune them.
'update'::
Fetch updates for remotes or remote groups in the repository as defined by
-remotes.<group>. If neither group nor remote is specified on the command line,
+`remotes.<group>`. If neither group nor remote is specified on the command line,
the configuration parameter remotes.default will be used; if
remotes.default is not defined, all remotes which do not have the
-configuration parameter remote.<name>.skipDefaultUpdate set to true will
+configuration parameter `remote.<name>.skipDefaultUpdate` set to true will
be updated. (See linkgit:git-config[1]).
+
With `--prune` option, run pruning against all the remotes that are updated.
@@ -203,6 +203,17 @@ The remote configuration is achieved using the `remote.origin.url` and
`remote.origin.fetch` configuration variables. (See
linkgit:git-config[1]).
+EXIT STATUS
+-----------
+
+On success, the exit status is `0`.
+
+When subcommands such as 'add', 'rename', and 'remove' can't find the
+remote in question, the exit status is `2`. When the remote already
+exists, the exit status is `3`.
+
+On any other error, the exit status may be any other non-zero value.
+
EXAMPLES
--------
diff --git a/Documentation/git-restore.txt b/Documentation/git-restore.txt
index 84c6c40..55bde91 100644
--- a/Documentation/git-restore.txt
+++ b/Documentation/git-restore.txt
@@ -40,6 +40,10 @@ OPTIONS
+
If not specified, the contents are restored from `HEAD` if `--staged` is
given, otherwise from the index.
++
+As a special case, you may use `"A...B"` as a shortcut for the
+merge base of `A` and `B` if there is exactly one merge base. You can
+leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
-p::
--patch::
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 025c911..5da6623 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -14,44 +14,8 @@ SYNOPSIS
DESCRIPTION
-----------
-List commits that are reachable by following the `parent` links from the
-given commit(s), but exclude commits that are reachable from the one(s)
-given with a '{caret}' in front of them. The output is given in reverse
-chronological order by default.
-
-You can think of this as a set operation. Commits given on the command
-line form a set of commits that are reachable from any of them, and then
-commits reachable from any of the ones given with '{caret}' in front are
-subtracted from that set. The remaining commits are what comes out in the
-command's output. Various other options and paths parameters can be used
-to further limit the result.
-
-Thus, the following command:
-
------------------------------------------------------------------------
- $ git rev-list foo bar ^baz
------------------------------------------------------------------------
-
-means "list all the commits which are reachable from 'foo' or 'bar', but
-not from 'baz'".
-
-A special notation "'<commit1>'..'<commit2>'" can be used as a
-short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of
-the following may be used interchangeably:
-
------------------------------------------------------------------------
- $ git rev-list origin..HEAD
- $ git rev-list HEAD ^origin
------------------------------------------------------------------------
-
-Another special notation is "'<commit1>'...'<commit2>'" which is useful
-for merges. The resulting set of commits is the symmetric difference
-between the two operands. The following two commands are equivalent:
-
------------------------------------------------------------------------
- $ git rev-list A B --not $(git merge-base --all A B)
- $ git rev-list A...B
------------------------------------------------------------------------
+:git-rev-list: 1
+include::rev-list-description.txt[]
'rev-list' is a very essential Git command, since it
provides the ability to build and traverse commit ancestry graphs. For
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index 044276e..bb92a4a 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -99,7 +99,7 @@ effect to your index in a row.
-s::
--signoff::
- Add Signed-off-by line at the end of the commit message.
+ Add a `Signed-off-by` trailer at the end of the commit message.
See the signoff option in linkgit:git-commit[1] for more information.
--strategy=<strategy>::
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 0a69810..b7bbbea 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -313,7 +313,7 @@ Automating
the value of `sendemail.identity`.
--[no-]signed-off-by-cc::
- If this is set, add emails found in Signed-off-by: or Cc: lines to the
+ If this is set, add emails found in the `Signed-off-by` trailer or Cc: lines to the
cc list. Default is the value of `sendemail.signedoffbycc` configuration
value; if that is unspecified, default to --signed-off-by-cc.
@@ -340,7 +340,7 @@ Automating
except for self (use 'self' for that).
- 'bodycc' will avoid including anyone mentioned in Cc lines in the
patch body (commit message) except for self (use 'self' for that).
-- 'sob' will avoid including anyone mentioned in Signed-off-by lines except
+- 'sob' will avoid including anyone mentioned in the Signed-off-by trailers except
for self (use 'self' for that).
- 'misc-by' will avoid including anyone mentioned in Acked-by,
Reviewed-by, Tested-by and other "-by" lines in the patch body,
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
index a72ea7f..fd93cd4 100644
--- a/Documentation/git-shortlog.txt
+++ b/Documentation/git-shortlog.txt
@@ -47,9 +47,38 @@ OPTIONS
Each pretty-printed commit will be rewrapped before it is shown.
+--group=<type>::
+ Group commits based on `<type>`. If no `--group` option is
+ specified, the default is `author`. `<type>` is one of:
++
+--
+ - `author`, commits are grouped by author
+ - `committer`, commits are grouped by committer (the same as `-c`)
+ - `trailer:<field>`, the `<field>` is interpreted as a case-insensitive
+ commit message trailer (see linkgit:git-interpret-trailers[1]). For
+ example, if your project uses `Reviewed-by` trailers, you might want
+ to see who has been reviewing with
+ `git shortlog -ns --group=trailer:reviewed-by`.
++
+Note that commits that do not include the trailer will not be counted.
+Likewise, commits with multiple trailers (e.g., multiple signoffs) may
+be counted more than once (but only once per unique trailer value in
+that commit).
++
+Shortlog will attempt to parse each trailer value as a `name <email>`
+identity. If successful, the mailmap is applied and the email is omitted
+unless the `--email` option is specified. If the value cannot be parsed
+as an identity, it will be taken literally and completely.
+--
++
+If `--group` is specified multiple times, commits are counted under each
+value (but again, only once per unique value in that commit). For
+example, `git shortlog --group=author --group=trailer:co-authored-by`
+counts both authors and co-authors.
+
-c::
--committer::
- Collect and show committer identities instead of authors.
+ This is an alias for `--group=committer`.
-w[<width>[,<indent1>[,<indent2>]]]::
Linewrap the output by wrapping each line at `width`. The first
diff --git a/Documentation/git-show-index.txt b/Documentation/git-show-index.txt
index 39b1d8e..e49318a 100644
--- a/Documentation/git-show-index.txt
+++ b/Documentation/git-show-index.txt
@@ -44,6 +44,8 @@ OPTIONS
valid values are 'sha1' and (if enabled) 'sha256'. The default is the
algorithm for the current repository (set by `extensions.objectFormat`), or
'sha1' if no value is set or outside a repository..
++
+include::object-format-disclaimer.txt[]
GIT
---
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 6624a14..67b143c 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -701,7 +701,7 @@ creating the branch or tag.
--use-log-author::
When retrieving svn commits into Git (as part of 'fetch', 'rebase', or
- 'dcommit' operations), look for the first `From:` or `Signed-off-by:` line
+ 'dcommit' operations), look for the first `From:` line or `Signed-off-by` trailer
in the log message and use that as the author string.
+
[verse]
@@ -710,7 +710,7 @@ config key: svn.useLogAuthor
--add-author-from::
When committing to svn from Git (as part of 'set-tree' or 'dcommit'
operations), if the existing log message doesn't already have a
- `From:` or `Signed-off-by:` line, append a `From:` line based on the
+ `From:` or `Signed-off-by` trailer, append a `From:` line based on the
Git commit's author string. If you use this, then `--use-log-author`
will retrieve a valid author string for all commits.
+
diff --git a/Documentation/git-switch.txt b/Documentation/git-switch.txt
index 3759c3a..5c438cd 100644
--- a/Documentation/git-switch.txt
+++ b/Documentation/git-switch.txt
@@ -103,6 +103,9 @@ ambiguous but exists on the 'origin' remote. See also
`checkout.defaultRemote` in linkgit:git-config[1].
+
`--guess` is the default behavior. Use `--no-guess` to disable it.
++
+The default behavior can be set via the `checkout.guess` configuration
+variable.
-f::
--force::
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index f6d9791..56656d1 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -15,7 +15,7 @@ SYNOPSIS
'git tag' [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>]
[--points-at <object>] [--column[=<options>] | --no-column]
[--create-reflog] [--sort=<key>] [--format=<format>]
- [--[no-]merged [<commit>]] [<pattern>...]
+ [--merged <commit>] [--no-merged <commit>] [<pattern>...]
'git tag' -v [--format=<format>] <tagname>...
DESCRIPTION
@@ -149,11 +149,11 @@ This option is only applicable when listing tags without annotation lines.
--merged [<commit>]::
Only list tags whose commits are reachable from the specified
- commit (`HEAD` if not specified), incompatible with `--no-merged`.
+ commit (`HEAD` if not specified).
--no-merged [<commit>]::
Only list tags whose commits are not reachable from the specified
- commit (`HEAD` if not specified), incompatible with `--merged`.
+ commit (`HEAD` if not specified).
--points-at <object>::
Only list tags of the given object (HEAD if not
@@ -377,6 +377,11 @@ $ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1
include::date-formats.txt[]
+NOTES
+-----
+
+include::ref-reachability-filters.txt[]
+
SEE ALSO
--------
linkgit:git-check-ref-format[1].
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index 3e737c2..d401234 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -148,12 +148,13 @@ still see a subset of the modifications.
LOGGING UPDATES
---------------
-If config parameter "core.logAllRefUpdates" is true and the ref is one under
-"refs/heads/", "refs/remotes/", "refs/notes/", or the symbolic ref HEAD; or
-the file "$GIT_DIR/logs/<ref>" exists then `git update-ref` will append
-a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all
-symbolic refs before creating the log name) describing the change
-in ref value. Log lines are formatted as:
+If config parameter "core.logAllRefUpdates" is true and the ref is one
+under "refs/heads/", "refs/remotes/", "refs/notes/", or a pseudoref
+like HEAD or ORIG_HEAD; or the file "$GIT_DIR/logs/<ref>" exists then
+`git update-ref` will append a line to the log file
+"$GIT_DIR/logs/<ref>" (dereferencing all symbolic refs before creating
+the log name) describing the change in ref value. Log lines are
+formatted as:
oldsha1 SP newsha1 SP committer LF
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 4796c3c..af06128 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -15,6 +15,7 @@ SYNOPSIS
'git worktree move' <worktree> <new-path>
'git worktree prune' [-n] [-v] [--expire <expire>]
'git worktree remove' [-f] <worktree>
+'git worktree repair' [<path>...]
'git worktree unlock' <worktree>
DESCRIPTION
@@ -25,11 +26,24 @@ Manage multiple working trees attached to the same repository.
A git repository can support multiple working trees, allowing you to check
out more than one branch at a time. With `git worktree add` a new working
tree is associated with the repository. This new working tree is called a
-"linked working tree" as opposed to the "main working tree" prepared by "git
-init" or "git clone". A repository has one main working tree (if it's not a
+"linked working tree" as opposed to the "main working tree" prepared by
+linkgit:git-init[1] or linkgit:git-clone[1].
+A repository has one main working tree (if it's not a
bare repository) and zero or more linked working trees. When you are done
with a linked working tree, remove it with `git worktree remove`.
+In its simplest form, `git worktree add <path>` automatically creates a
+new branch whose name is the final component of `<path>`, which is
+convenient if you plan to work on a new topic. For instance, `git
+worktree add ../hotfix` creates new branch `hotfix` and checks it out at
+path `../hotfix`. To instead work on an existing branch in a new working
+tree, use `git worktree add <path> <branch>`. On the other hand, if you
+just plan to make some experimental changes or do testing without
+disturbing existing development, it is often convenient to create a
+'throwaway' working tree not associated with any branch. For instance,
+`git worktree add -d <path>` creates a new working tree with a detached
+`HEAD` at the same commit as the current branch.
+
If a working tree is deleted without using `git worktree remove`, then
its associated administrative files, which reside in the repository
(see "DETAILS" below), will eventually be removed automatically (see
@@ -48,10 +62,10 @@ add <path> [<commit-ish>]::
Create `<path>` and checkout `<commit-ish>` into it. The new working directory
is linked to the current repository, sharing everything except working
-directory specific files such as HEAD, index, etc. `-` may also be
-specified as `<commit-ish>`; it is synonymous with `@{-1}`.
+directory specific files such as `HEAD`, `index`, etc. As a convenience,
+`<commit-ish>` may be a bare "`-`", which is synonymous with `@{-1}`.
+
-If <commit-ish> is a branch name (call it `<branch>`) and is not found,
+If `<commit-ish>` is a branch name (call it `<branch>`) and is not found,
and neither `-b` nor `-B` nor `--detach` are used, but there does
exist a tracking branch in exactly one remote (call it `<remote>`)
with a matching name, treat as equivalent to:
@@ -66,24 +80,25 @@ one for the purposes of disambiguation, even if the `<branch>` isn't
unique across all remotes. Set it to
e.g. `checkout.defaultRemote=origin` to always checkout remote
branches from there if `<branch>` is ambiguous but exists on the
-'origin' remote. See also `checkout.defaultRemote` in
+`origin` remote. See also `checkout.defaultRemote` in
linkgit:git-config[1].
+
If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
-then, as a convenience, the new worktree is associated with a branch
+then, as a convenience, the new working tree is associated with a branch
(call it `<branch>`) named after `$(basename <path>)`. If `<branch>`
-doesn't exist, a new branch based on HEAD is automatically created as
+doesn't exist, a new branch based on `HEAD` is automatically created as
if `-b <branch>` was given. If `<branch>` does exist, it will be
-checked out in the new worktree, if it's not checked out anywhere
-else, otherwise the command will refuse to create the worktree (unless
+checked out in the new working tree, if it's not checked out anywhere
+else, otherwise the command will refuse to create the working tree (unless
`--force` is used).
list::
-List details of each worktree. The main worktree is listed first, followed by
-each of the linked worktrees. The output details include if the worktree is
-bare, the revision currently checked out, and the branch currently checked out
-(or 'detached HEAD' if none).
+List details of each working tree. The main working tree is listed first,
+followed by each of the linked working trees. The output details include
+whether the working tree is bare, the revision currently checked out, the
+branch currently checked out (or "detached HEAD" if none), and "locked" if
+the worktree is locked.
lock::
@@ -96,11 +111,14 @@ with `--reason`.
move::
Move a working tree to a new location. Note that the main working tree
-or linked working trees containing submodules cannot be moved.
+or linked working trees containing submodules cannot be moved with this
+command. (The `git worktree repair` command, however, can reestablish
+the connection with linked working trees if you move the main working
+tree manually.)
prune::
-Prune working tree information in $GIT_DIR/worktrees.
+Prune working tree information in `$GIT_DIR/worktrees`.
remove::
@@ -109,6 +127,23 @@ and no modification in tracked files) can be removed. Unclean working
trees or ones with submodules can be removed with `--force`. The main
working tree cannot be removed.
+repair [<path>...]::
+
+Repair working tree administrative files, if possible, if they have
+become corrupted or outdated due to external factors.
++
+For instance, if the main working tree (or bare repository) is moved,
+linked working trees will be unable to locate it. Running `repair` in
+the main working tree will reestablish the connection from linked
+working trees back to the main working tree.
++
+Similarly, if a linked working tree is moved without using `git worktree
+move`, the main working tree (or bare repository) will be unable to
+locate it. Running `repair` within the recently-moved working tree will
+reestablish the connection. If multiple linked working trees are moved,
+running `repair` from any working tree with each tree's new `<path>` as
+an argument, will reestablish the connection to all the specified paths.
+
unlock::
Unlock a working tree, allowing it to be pruned, moved or deleted.
@@ -128,7 +163,7 @@ OPTIONS
`move` refuses to move a locked working tree unless `--force` is specified
twice. If the destination is already assigned to some other working tree but is
missing (for instance, if `<new-path>` was deleted manually), then `--force`
-allows the move to proceed; use --force twice if the destination is locked.
+allows the move to proceed; use `--force` twice if the destination is locked.
+
`remove` refuses to remove an unclean working tree unless `--force` is used.
To remove a locked working tree, specify `--force` twice.
@@ -137,13 +172,14 @@ To remove a locked working tree, specify `--force` twice.
-B <new-branch>::
With `add`, create a new branch named `<new-branch>` starting at
`<commit-ish>`, and check out `<new-branch>` into the new working tree.
- If `<commit-ish>` is omitted, it defaults to HEAD.
+ If `<commit-ish>` is omitted, it defaults to `HEAD`.
By default, `-b` refuses to create a new branch if it already
exists. `-B` overrides this safeguard, resetting `<new-branch>` to
`<commit-ish>`.
+-d::
--detach::
- With `add`, detach HEAD in the new working tree. See "DETACHED HEAD"
+ With `add`, detach `HEAD` in the new working tree. See "DETACHED HEAD"
in linkgit:git-checkout[1].
--[no-]checkout::
@@ -154,7 +190,7 @@ To remove a locked working tree, specify `--force` twice.
--[no-]guess-remote::
With `worktree add <path>`, without `<commit-ish>`, instead
- of creating a new branch from HEAD, if there exists a tracking
+ of creating a new branch from `HEAD`, if there exists a tracking
branch in exactly one remote matching the basename of `<path>`,
base the new branch on the remote-tracking branch, and mark
the remote-tracking branch as "upstream" from the new branch.
@@ -166,12 +202,12 @@ This can also be set up as the default behaviour by using the
When creating a new branch, if `<commit-ish>` is a branch,
mark it as "upstream" from the new branch. This is the
default if `<commit-ish>` is a remote-tracking branch. See
- "--track" in linkgit:git-branch[1] for details.
+ `--track` in linkgit:git-branch[1] for details.
--lock::
Keep the working tree locked after creation. This is the
equivalent of `git worktree lock` after `git worktree add`,
- but without race condition.
+ but without a race condition.
-n::
--dry-run::
@@ -185,14 +221,14 @@ This can also be set up as the default behaviour by using the
-q::
--quiet::
- With 'add', suppress feedback messages.
+ With `add`, suppress feedback messages.
-v::
--verbose::
With `prune`, report all removals.
--expire <time>::
- With `prune`, only expire unused working trees older than <time>.
+ With `prune`, only expire unused working trees older than `<time>`.
--reason <string>::
With `lock`, an explanation why the working tree is locked.
@@ -202,48 +238,48 @@ This can also be set up as the default behaviour by using the
absolute.
+
If the last path components in the working tree's path is unique among
-working trees, it can be used to identify worktrees. For example if
-you only have two working trees, at "/abc/def/ghi" and "/abc/def/ggg",
-then "ghi" or "def/ghi" is enough to point to the former working tree.
+working trees, it can be used to identify a working tree. For example if
+you only have two working trees, at `/abc/def/ghi` and `/abc/def/ggg`,
+then `ghi` or `def/ghi` is enough to point to the former working tree.
REFS
----
In multiple working trees, some refs may be shared between all working
-trees, some refs are local. One example is HEAD is different for all
-working trees. This section is about the sharing rules and how to access
+trees and some refs are local. One example is `HEAD` which is different for each
+working tree. This section is about the sharing rules and how to access
refs of one working tree from another.
In general, all pseudo refs are per working tree and all refs starting
-with "refs/" are shared. Pseudo refs are ones like HEAD which are
-directly under GIT_DIR instead of inside GIT_DIR/refs. There is one
-exception to this: refs inside refs/bisect and refs/worktree is not
+with `refs/` are shared. Pseudo refs are ones like `HEAD` which are
+directly under `$GIT_DIR` instead of inside `$GIT_DIR/refs`. There are
+exceptions, however: refs inside `refs/bisect` and `refs/worktree` are not
shared.
Refs that are per working tree can still be accessed from another
-working tree via two special paths, main-worktree and worktrees. The
-former gives access to per-worktree refs of the main working tree,
+working tree via two special paths, `main-worktree` and `worktrees`. The
+former gives access to per-working tree refs of the main working tree,
while the latter to all linked working trees.
-For example, main-worktree/HEAD or main-worktree/refs/bisect/good
-resolve to the same value as the main working tree's HEAD and
-refs/bisect/good respectively. Similarly, worktrees/foo/HEAD or
-worktrees/bar/refs/bisect/bad are the same as
-GIT_COMMON_DIR/worktrees/foo/HEAD and
-GIT_COMMON_DIR/worktrees/bar/refs/bisect/bad.
+For example, `main-worktree/HEAD` or `main-worktree/refs/bisect/good`
+resolve to the same value as the main working tree's `HEAD` and
+`refs/bisect/good` respectively. Similarly, `worktrees/foo/HEAD` or
+`worktrees/bar/refs/bisect/bad` are the same as
+`$GIT_COMMON_DIR/worktrees/foo/HEAD` and
+`$GIT_COMMON_DIR/worktrees/bar/refs/bisect/bad`.
-To access refs, it's best not to look inside GIT_DIR directly. Instead
+To access refs, it's best not to look inside `$GIT_DIR` directly. Instead
use commands such as linkgit:git-rev-parse[1] or linkgit:git-update-ref[1]
which will handle refs correctly.
CONFIGURATION FILE
------------------
-By default, the repository "config" file is shared across all working
+By default, the repository `config` file is shared across all working
trees. If the config variables `core.bare` or `core.worktree` are
already present in the config file, they will be applied to the main
working trees only.
In order to have configuration specific to working trees, you can turn
-on "worktreeConfig" extension, e.g.:
+on the `worktreeConfig` extension, e.g.:
------------
$ git config extensions.worktreeConfig true
@@ -255,7 +291,7 @@ configuration in this file with `git config --worktree`. Older Git
versions will refuse to access repositories with this extension.
Note that in this file, the exception for `core.bare` and `core.worktree`
-is gone. If you have them in $GIT_DIR/config before, you must move
+is gone. If they exist in `$GIT_DIR/config`, you must move
them to the `config.worktree` of the main working tree. You may also
take this opportunity to review and move other configuration that you
do not want to share to all working trees:
@@ -268,7 +304,7 @@ do not want to share to all working trees:
DETAILS
-------
Each linked working tree has a private sub-directory in the repository's
-$GIT_DIR/worktrees directory. The private sub-directory's name is usually
+`$GIT_DIR/worktrees` directory. The private sub-directory's name is usually
the base name of the linked working tree's path, possibly appended with a
number to make it unique. For example, when `$GIT_DIR=/path/main/.git` the
command `git worktree add /path/other/test-next next` creates the linked
@@ -276,51 +312,52 @@ working tree in `/path/other/test-next` and also creates a
`$GIT_DIR/worktrees/test-next` directory (or `$GIT_DIR/worktrees/test-next1`
if `test-next` is already taken).
-Within a linked working tree, $GIT_DIR is set to point to this private
+Within a linked working tree, `$GIT_DIR` is set to point to this private
directory (e.g. `/path/main/.git/worktrees/test-next` in the example) and
-$GIT_COMMON_DIR is set to point back to the main working tree's $GIT_DIR
+`$GIT_COMMON_DIR` is set to point back to the main working tree's `$GIT_DIR`
(e.g. `/path/main/.git`). These settings are made in a `.git` file located at
the top directory of the linked working tree.
Path resolution via `git rev-parse --git-path` uses either
-$GIT_DIR or $GIT_COMMON_DIR depending on the path. For example, in the
+`$GIT_DIR` or `$GIT_COMMON_DIR` depending on the path. For example, in the
linked working tree `git rev-parse --git-path HEAD` returns
`/path/main/.git/worktrees/test-next/HEAD` (not
`/path/other/test-next/.git/HEAD` or `/path/main/.git/HEAD`) while `git
rev-parse --git-path refs/heads/master` uses
-$GIT_COMMON_DIR and returns `/path/main/.git/refs/heads/master`,
-since refs are shared across all working trees, except refs/bisect and
-refs/worktree.
+`$GIT_COMMON_DIR` and returns `/path/main/.git/refs/heads/master`,
+since refs are shared across all working trees, except `refs/bisect` and
+`refs/worktree`.
See linkgit:gitrepository-layout[5] for more information. The rule of
thumb is do not make any assumption about whether a path belongs to
-$GIT_DIR or $GIT_COMMON_DIR when you need to directly access something
-inside $GIT_DIR. Use `git rev-parse --git-path` to get the final path.
+`$GIT_DIR` or `$GIT_COMMON_DIR` when you need to directly access something
+inside `$GIT_DIR`. Use `git rev-parse --git-path` to get the final path.
-If you manually move a linked working tree, you need to update the 'gitdir' file
+If you manually move a linked working tree, you need to update the `gitdir` file
in the entry's directory. For example, if a linked working tree is moved
to `/newpath/test-next` and its `.git` file points to
`/path/main/.git/worktrees/test-next`, then update
`/path/main/.git/worktrees/test-next/gitdir` to reference `/newpath/test-next`
-instead.
+instead. Better yet, run `git worktree repair` to reestablish the connection
+automatically.
-To prevent a $GIT_DIR/worktrees entry from being pruned (which
+To prevent a `$GIT_DIR/worktrees` entry from being pruned (which
can be useful in some situations, such as when the
entry's working tree is stored on a portable device), use the
`git worktree lock` command, which adds a file named
-'locked' to the entry's directory. The file contains the reason in
+`locked` to the entry's directory. The file contains the reason in
plain text. For example, if a linked working tree's `.git` file points
to `/path/main/.git/worktrees/test-next` then a file named
`/path/main/.git/worktrees/test-next/locked` will prevent the
`test-next` entry from being pruned. See
linkgit:gitrepository-layout[5] for details.
-When extensions.worktreeConfig is enabled, the config file
+When `extensions.worktreeConfig` is enabled, the config file
`.git/worktrees/<id>/config.worktree` is read after `.git/config` is.
LIST OUTPUT FORMAT
------------------
-The worktree list command has two output formats. The default format shows the
+The `worktree list` command has two output formats. The default format shows the
details on a single line with columns. For example:
------------
@@ -333,10 +370,10 @@ $ git worktree list
Porcelain Format
~~~~~~~~~~~~~~~~
The porcelain format has a line per attribute. Attributes are listed with a
-label and value separated by a single space. Boolean attributes (like 'bare'
-and 'detached') are listed as a label only, and are only present if and only
-if the value is true. The first attribute of a worktree is always `worktree`,
-an empty line indicates the end of the record. For example:
+label and value separated by a single space. Boolean attributes (like `bare`
+and `detached`) are listed as a label only, and are present only
+if the value is true. The first attribute of a working tree is always
+`worktree`, an empty line indicates the end of the record. For example:
------------
$ git worktree list --porcelain
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 3e50065..c463b93 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -304,6 +304,13 @@ users typically do not use them directly.
include::cmds-purehelpers.txt[]
+Guides
+------
+
+The following documentation pages are guides about Git concepts.
+
+include::cmds-guide.txt[]
+
Configuration Mechanism
-----------------------
@@ -497,7 +504,8 @@ double-quotes and respecting backslash escapes. E.g., the value
If this variable is set, the default hash algorithm for new
repositories will be set to this value. This value is currently
ignored when cloning; the setting of the remote repository
- is used instead. The default is "sha1".
+ is used instead. The default is "sha1". THIS VARIABLE IS
+ EXPERIMENTAL! See `--object-format` in linkgit:git-init[1].
Git Commits
~~~~~~~~~~~
@@ -543,8 +551,9 @@ Git Diffs
`GIT_EXTERNAL_DIFF`::
When the environment variable `GIT_EXTERNAL_DIFF` is set, the
- program named by it is called, instead of the diff invocation
- described above. For a path that is added, removed, or modified,
+ 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
@@ -597,6 +606,12 @@ other
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
+ linkit::git-rebase[1] and the `sequence.editor` option in
+ linkit::git-config[1].
+
`GIT_SSH`::
`GIT_SSH_COMMAND`::
If either of these environment variables is set then 'git fetch'
@@ -707,6 +722,10 @@ of clones and fetches.
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.
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 2d0a037..e84e104 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -802,6 +802,9 @@ patterns are available:
- `ada` suitable for source code in the Ada language.
+- `bash` suitable for source code in the Bourne-Again SHell language.
+ Covers a superset of POSIX shell function definitions.
+
- `bibtex` suitable for files with BibTeX coded references.
- `cpp` suitable for source code in the C and C++ languages.
diff --git a/Documentation/gitcredentials.txt b/Documentation/gitcredentials.txt
index 9e481ae..758bf39 100644
--- a/Documentation/gitcredentials.txt
+++ b/Documentation/gitcredentials.txt
@@ -3,7 +3,7 @@ gitcredentials(7)
NAME
----
-gitcredentials - providing usernames and passwords to Git
+gitcredentials - Providing usernames and passwords to Git
SYNOPSIS
--------
diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt
index 9cd7a59..afdaeab 100644
--- a/Documentation/gitfaq.txt
+++ b/Documentation/gitfaq.txt
@@ -241,6 +241,59 @@ How do I know if I want to do a fetch or a pull?::
ignore the upstream changes. A pull consists of a fetch followed
immediately by either a merge or rebase. See linkgit:git-pull[1].
+Merging and Rebasing
+--------------------
+
+[[long-running-squash-merge]]
+What kinds of problems can occur when merging long-lived branches with squash merges?::
+ In general, there are a variety of problems that can occur when using squash
+ merges to merge two branches multiple times. These can include seeing extra
+ commits in `git log` output, with a GUI, or when using the `...` notation to
+ express a range, as well as the possibility of needing to re-resolve conflicts
+ again and again.
++
+When Git does a normal merge between two branches, it considers exactly three
+points: the two branches and a third commit, called the _merge base_, which is
+usually the common ancestor of the commits. The result of the merge is the sum
+of the changes between the merge base and each head. When you merge two
+branches with a regular merge commit, this results in a new commit which will
+end up as a merge base when they're merged again, because there is now a new
+common ancestor. Git doesn't have to consider changes that occurred before the
+merge base, so you don't have to re-resolve any conflicts you resolved before.
++
+When you perform a squash merge, a merge commit isn't created; instead, the
+changes from one side are applied as a regular commit to the other side. This
+means that the merge base for these branches won't have changed, and so when Git
+goes to perform its next merge, it considers all of the changes that it
+considered the last time plus the new changes. That means any conflicts may
+need to be re-resolved. Similarly, anything using the `...` notation in `git
+diff`, `git log`, or a GUI will result in showing all of the changes since the
+original merge base.
++
+As a consequence, if you want to merge two long-lived branches repeatedly, it's
+best to always use a regular merge commit.
+
+[[merge-two-revert-one]]
+If I make a change on two branches but revert it on one, why does the merge of those branches include the change?::
+ By default, when Git does a merge, it uses a strategy called the recursive
+ strategy, which does a fancy three-way merge. In such a case, when Git
+ performs the merge, it considers exactly three points: the two heads and a
+ third point, called the _merge base_, which is usually the common ancestor of
+ those commits. Git does not consider the history or the individual commits
+ that have happened on those branches at all.
++
+As a result, if both sides have a change and one side has reverted that change,
+the result is to include the change. This is because the code has changed on
+one side and there is no net change on the other, and in this scenario, Git
+adopts the change.
++
+If this is a problem for you, you can do a rebase instead, rebasing the branch
+with the revert onto the other branch. A rebase in this scenario will revert
+the change, because a rebase applies each individual commit, including the
+revert. Note that rebases rewrite history, so you should avoid rebasing
+published branches unless you're sure you're comfortable with that. See the
+NOTES section in linkgit:git-rebase[1] for more details.
+
Hooks
-----
@@ -310,6 +363,39 @@ information about how to configure files as text or binary.
You can also control this behavior with the `core.whitespace` setting if you
don't wish to remove the carriage returns from your line endings.
+[[always-modified-files-case]]
+Why do I have a file that's always modified?::
+ Internally, Git always stores file names as sequences of bytes and doesn't
+ perform any encoding or case folding. However, Windows and macOS by default
+ both perform case folding on file names. As a result, it's possible to end up
+ with multiple files or directories whose names differ only in case. Git can
+ handle this just fine, but the file system can store only one of these files,
+ so when Git reads the other file to see its contents, it looks modified.
++
+It's best to remove one of the files such that you only have one file. You can
+do this with commands like the following (assuming two files `AFile.txt` and
+`afile.txt`) on an otherwise clean working tree:
++
+----
+$ git rm --cached AFile.txt
+$ git commit -m 'Remove files conflicting in case'
+$ git checkout .
+----
++
+This avoids touching the disk, but removes the additional file. Your project
+may prefer to adopt a naming convention, such as all-lowercase names, to avoid
+this problem from occurring again; such a convention can be checked using a
+`pre-receive` hook or as part of a continuous integration (CI) system.
++
+It is also possible for perpetually modified files to occur on any platform if a
+smudge or clean filter is in use on your system but a file was previously
+committed without running the smudge or clean filter. To fix this, run the
+following on an otherwise clean working tree:
++
+----
+$ git add --renormalize .
+----
+
[[recommended-storage-settings]]
What's the recommended way to store files in Git?::
While Git can store and handle any file of any type, there are some
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 31b601e..ffccfc7 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -164,7 +164,7 @@ can also be used to refuse the commit after inspecting the message
file.
The default 'commit-msg' hook, when enabled, detects duplicate
-"Signed-off-by" lines, and aborts the commit if one is found.
+`Signed-off-by` trailers, and aborts the commit if one is found.
post-commit
~~~~~~~~~~~
@@ -193,7 +193,9 @@ worktree. The hook is given three parameters: the ref of the previous HEAD,
the ref of the new HEAD (which may or may not have changed), and a flag
indicating whether the checkout was a branch checkout (changing branches,
flag=1) or a file checkout (retrieving a file from the index, flag=0).
-This hook cannot affect the outcome of `git switch` or `git checkout`.
+This hook cannot affect the outcome of `git switch` or `git checkout`,
+other than that the hook's exit status becomes the exit status of
+these two commands.
It is also run after linkgit:git-clone[1], unless the `--no-checkout` (`-n`) option is
used. The first parameter given to the hook is the null-ref, the second the
@@ -333,6 +335,68 @@ The default 'update' hook, when enabled--and with
`hooks.allowunannotated` config option unset or set to false--prevents
unannotated tags to be pushed.
+[[proc-receive]]
+proc-receive
+~~~~~~~~~~~~
+
+This hook is invoked by linkgit:git-receive-pack[1]. If the server has
+set the multi-valued config variable `receive.procReceiveRefs`, and the
+commands sent to 'receive-pack' have matching reference names, these
+commands will be executed by this hook, instead of by the internal
+`execute_commands()` function. This hook is responsible for updating
+the relevant references and reporting the results back to 'receive-pack'.
+
+This hook executes once for the receive operation. It takes no
+arguments, but uses a pkt-line format protocol to communicate with
+'receive-pack' to read commands, push-options and send results. In the
+following example for the protocol, the letter 'S' stands for
+'receive-pack' and the letter 'H' stands for this hook.
+
+ # Version and features negotiation.
+ S: PKT-LINE(version=1\0push-options atomic...)
+ S: flush-pkt
+ H: PKT-LINE(version=1\0push-options...)
+ H: flush-pkt
+
+ # Send commands from server to the hook.
+ S: PKT-LINE(<old-oid> <new-oid> <ref>)
+ S: ... ...
+ S: flush-pkt
+ # Send push-options only if the 'push-options' feature is enabled.
+ S: PKT-LINE(push-option)
+ S: ... ...
+ S: flush-pkt
+
+ # Receive result from the hook.
+ # OK, run this command successfully.
+ H: PKT-LINE(ok <ref>)
+ # NO, I reject it.
+ H: PKT-LINE(ng <ref> <reason>)
+ # Fall through, let 'receive-pack' to execute it.
+ H: PKT-LINE(ok <ref>)
+ H: PKT-LINE(option fall-through)
+ # OK, but has an alternate reference. The alternate reference name
+ # and other status can be given in option directives.
+ H: PKT-LINE(ok <ref>)
+ H: PKT-LINE(option refname <refname>)
+ H: PKT-LINE(option old-oid <old-oid>)
+ H: PKT-LINE(option new-oid <new-oid>)
+ H: PKT-LINE(option forced-update)
+ H: ... ...
+ H: flush-pkt
+
+Each command for the 'proc-receive' hook may point to a pseudo-reference
+and always has a zero-old as its old-oid, while the 'proc-receive' hook
+may update an alternate reference and the alternate reference may exist
+already with a non-zero old-oid. For this case, this hook will use
+"option" directives to report extended attributes for the reference given
+by the leading "ok" directive.
+
+The report of the commands of this hook should have the same order as
+the input. The exit status of the 'proc-receive' hook only determines
+the success or failure of the group of commands sent to it, unless
+atomic push is in use.
+
[[post-receive]]
post-receive
~~~~~~~~~~~~
@@ -591,7 +655,7 @@ p4-post-changelist
This hook is invoked by `git-p4 submit`.
The `p4-post-changelist` hook is invoked after the submit has
-successfully occured in P4. It takes no parameters and is meant
+successfully occurred in P4. It takes no parameters and is meant
primarily for notification and cannot affect the outcome of the
git p4 submit action.
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index c653ebb..d50e9ed 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -98,25 +98,7 @@ linkgit:git-rev-list[1] for a complete list.
(See "History simplification" in linkgit:git-log[1] for a more
detailed explanation.)
--L<start>,<end>:<file>::
--L:<funcname>:<file>::
-
- Trace the evolution of the line range given by "<start>,<end>"
- (or the function name regex <funcname>) within the <file>. You may
- not give any pathspec limiters. This is currently limited to
- a walk starting from a single revision, i.e., you may only
- give zero or one positive revision arguments, and
- <start> and <end> (or <funcname>) must exist in the starting revision.
- You can specify this option more than once. Implies `--patch`.
- Patch output can be suppressed using `--no-patch`, but other diff formats
- (namely `--raw`, `--numstat`, `--shortstat`, `--dirstat`, `--summary`,
- `--name-only`, `--name-status`, `--check`) are not currently implemented.
-+
-*Note:* gitk (unlike linkgit:git-log[1]) currently only understands
-this option if you specify it "glued together" with its argument. Do
-*not* put a space after `-L`.
-+
-include::line-range-format.txt[]
+include::line-range-options.txt[]
<revision range>::
diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
index f9f4e65..891c8da 100644
--- a/Documentation/gitsubmodules.txt
+++ b/Documentation/gitsubmodules.txt
@@ -225,10 +225,10 @@ presence of the .url field.
Workflow for a third party library
----------------------------------
- # add a submodule
+ # Add a submodule
git submodule add <url> <path>
- # occasionally update the submodule to a new version:
+ # Occasionally update the submodule to a new version:
git -C <path> checkout <new version>
git add <path>
git commit -m "update submodule to new version"
@@ -246,20 +246,23 @@ Workflow for an artificially split repo
# regular commands recurse into submodules by default
git config --global submodule.recurse true
- # Unlike the other commands below clone still needs
+ # Unlike most other commands below, clone still needs
# its own recurse flag:
git clone --recurse <URL> <directory>
cd <directory>
# Get to know the code:
git grep foo
- git ls-files
+ git ls-files --recurse-submodules
+
+[NOTE]
+`git ls-files` also requires its own `--recurse-submodules` flag.
# Get new code
git fetch
git pull --rebase
- # change worktree
+ # Change worktree
git checkout
git reset
@@ -267,12 +270,12 @@ Implementation details
----------------------
When cloning or pulling a repository containing submodules the submodules
-will not be checked out by default; You can instruct 'clone' to recurse
-into submodules. The 'init' and 'update' subcommands of 'git submodule'
+will not be checked out by default; you can instruct `clone` to recurse
+into submodules. The `init` and `update` subcommands of `git submodule`
will maintain submodules checked out and at an appropriate revision in
-your working tree. Alternatively you can set 'submodule.recurse' to have
-'checkout' recursing into submodules (note that 'submodule.recurse' also
-affects other git commands, see linkgit:git-config[1] for a complete list).
+your working tree. Alternatively you can set `submodule.recurse` to have
+`checkout` recursing into submodules (note that `submodule.recurse` also
+affects other Git commands, see linkgit:git-config[1] for a complete list).
SEE ALSO
diff --git a/Documentation/line-range-format.txt b/Documentation/line-range-format.txt
index 829676f..9b51e9f 100644
--- a/Documentation/line-range-format.txt
+++ b/Documentation/line-range-format.txt
@@ -1,30 +1,32 @@
-<start> and <end> can take one of these forms:
+'<start>' and '<end>' can take one of these forms:
- number
+
-If <start> or <end> is a number, it specifies an
+If '<start>' or '<end>' is a number, it specifies an
absolute line number (lines count from 1).
+
-- /regex/
+- `/regex/`
+
This form will use the first line matching the given
-POSIX regex. If <start> is a regex, it will search from the end of
+POSIX regex. If '<start>' is a regex, it will search from the end of
the previous `-L` range, if any, otherwise from the start of file.
-If <start> is ``^/regex/'', it will search from the start of file.
-If <end> is a regex, it will search
-starting at the line given by <start>.
+If '<start>' is `^/regex/`, it will search from the start of file.
+If '<end>' is a regex, it will search
+starting at the line given by '<start>'.
+
- +offset or -offset
+
-This is only valid for <end> and will specify a number
-of lines before or after the line given by <start>.
+This is only valid for '<end>' and will specify a number
+of lines before or after the line given by '<start>'.
+
-If ``:<funcname>'' is given in place of <start> and <end>, it is a
+If `:<funcname>` is given in place of '<start>' and '<end>', it is a
regular expression that denotes the range from the first funcname line
-that matches <funcname>, up to the next funcname line. ``:<funcname>''
+that matches '<funcname>', up to the next funcname line. `:<funcname>`
searches from the end of the previous `-L` range, if any, otherwise
-from the start of file. ``^:<funcname>'' searches from the start of
-file.
+from the start of file. `^:<funcname>` searches from the start of
+file. The function names are determined in the same way as `git diff`
+works out patch hunk headers (see 'Defining a custom hunk-header'
+in linkgit:gitattributes[5]).
diff --git a/Documentation/line-range-options.txt b/Documentation/line-range-options.txt
new file mode 100644
index 0000000..8e295a6
--- /dev/null
+++ b/Documentation/line-range-options.txt
@@ -0,0 +1,15 @@
+-L<start>,<end>:<file>::
+-L:<funcname>:<file>::
+
+ Trace the evolution of the line range given by '<start>,<end>',
+ or by the function name regex '<funcname>', within the '<file>'. You may
+ not give any pathspec limiters. This is currently limited to
+ a walk starting from a single revision, i.e., you may only
+ give zero or one positive revision arguments, and
+ '<start>' and '<end>' (or '<funcname>') must exist in the starting revision.
+ You can specify this option more than once. Implies `--patch`.
+ Patch output can be suppressed using `--no-patch`, but other diff formats
+ (namely `--raw`, `--numstat`, `--shortstat`, `--dirstat`, `--summary`,
+ `--name-only`, `--name-status`, `--check`) are not currently implemented.
++
+include::line-range-format.txt[]
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 80d4831..eb0aabd 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -77,16 +77,7 @@ When not possible, refuse to merge and exit with a non-zero status.
With --no-log do not list one-line descriptions from the
actual commits being merged.
---signoff::
---no-signoff::
- Add Signed-off-by line by the committer at the end of the commit
- log message. The meaning of a signoff depends on the project,
- but it typically certifies that committer has
- the rights to submit this work under the same license and
- agrees to a Developer Certificate of Origin
- (see http://developercertificate.org/ for more information).
-+
-With --no-signoff do not add a Signed-off-by line.
+include::signoff-option.txt[]
--stat::
-n::
diff --git a/Documentation/object-format-disclaimer.txt b/Documentation/object-format-disclaimer.txt
new file mode 100644
index 0000000..4cb106f
--- /dev/null
+++ b/Documentation/object-format-disclaimer.txt
@@ -0,0 +1,6 @@
+THIS OPTION IS EXPERIMENTAL! SHA-256 support is experimental and still
+in an early stage. A SHA-256 repository will in general not be able to
+share work with "regular" SHA-1 repositories. It should be assumed
+that, e.g., Git internal file formats in relation to SHA-256
+repositories may change in backwards-incompatible ways. Only use
+`--object-format=sha256` for testing purposes.
diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt
index 7a6da6d..27ddaf8 100644
--- a/Documentation/pretty-options.txt
+++ b/Documentation/pretty-options.txt
@@ -16,17 +16,17 @@ configuration (see linkgit:git-config[1]).
--abbrev-commit::
Instead of showing the full 40-byte hexadecimal commit object
- name, show only a partial prefix. Non default number of
- digits can be specified with "--abbrev=<n>" (which also modifies
- diff output, if it is displayed).
+ name, show a prefix that names the object uniquely.
+ "--abbrev=<n>" (which also modifies diff output, if it is displayed)
+ option can be used to specify the minimum length of the prefix.
+
This should make "--pretty=oneline" a whole lot more readable for
people using 80-column terminals.
--no-abbrev-commit::
Show the full 40-byte hexadecimal commit object name. This negates
- `--abbrev-commit` and those options which imply it such as
- "--oneline". It also overrides the `log.abbrevCommit` variable.
+ `--abbrev-commit`, either explicit or implied by other options such
+ as "--oneline". It also overrides the `log.abbrevCommit` variable.
--oneline::
This is a shorthand for "--pretty=oneline --abbrev-commit"
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index 95ea849..95a7390 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -30,6 +30,22 @@ The colon can be omitted when <dst> is empty. <src> is
typically a ref, but it can also be a fully spelled hex object
name.
+
+A <refspec> may contain a `*` in its <src> to indicate a simple pattern
+match. Such a refspec functions like a glob that matches any ref with the
+same prefix. A pattern <refspec> must have a `*` in both the <src> and
+<dst>. It will map refs to the destination by replacing the `*` with the
+contents matched from the source.
++
+If a refspec is prefixed by `^`, it will be interpreted as a negative
+refspec. Rather than specifying which refs to fetch or which local refs to
+update, such a refspec will instead specify refs to exclude. A ref will be
+considered to match if it matches at least one positive refspec, and does
+not match any negative refspec. Negative refspecs can be useful to restrict
+the scope of a pattern refspec so that it will not include specific refs.
+Negative refspecs can themselves be pattern refspecs. However, they may only
+contain a <src> and do not specify a <dst>. Fully spelled out hex object
+names are also not supported.
++
`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`;
it requests fetching everything up to the given tag.
+
diff --git a/Documentation/ref-reachability-filters.txt b/Documentation/ref-reachability-filters.txt
new file mode 100644
index 0000000..9bae46d
--- /dev/null
+++ b/Documentation/ref-reachability-filters.txt
@@ -0,0 +1,7 @@
+When combining multiple `--contains` and `--no-contains` filters, only
+references that contain at least one of the `--contains` commits and
+contain none of the `--no-contains` commits are shown.
+
+When combining multiple `--merged` and `--no-merged` filters, only
+references that are reachable from at least one of the `--merged`
+commits and from none of the `--no-merged` commits are shown.
diff --git a/Documentation/rev-list-description.txt b/Documentation/rev-list-description.txt
new file mode 100644
index 0000000..a9efa7f
--- /dev/null
+++ b/Documentation/rev-list-description.txt
@@ -0,0 +1,61 @@
+List commits that are reachable by following the `parent` links from the
+given commit(s), but exclude commits that are reachable from the one(s)
+given with a '{caret}' in front of them. The output is given in reverse
+chronological order by default.
+
+You can think of this as a set operation. Commits reachable from any of
+the commits given on the command line form a set, and then commits reachable
+from any of the ones given with '{caret}' in front are subtracted from that
+set. The remaining commits are what comes out in the command's output.
+Various other options and paths parameters can be used to further limit the
+result.
+
+Thus, the following command:
+
+ifdef::git-rev-list[]
+-----------------------------------------------------------------------
+$ git rev-list foo bar ^baz
+-----------------------------------------------------------------------
+endif::git-rev-list[]
+ifdef::git-log[]
+-----------------------------------------------------------------------
+$ git log foo bar ^baz
+-----------------------------------------------------------------------
+endif::git-log[]
+
+means "list all the commits which are reachable from 'foo' or 'bar', but
+not from 'baz'".
+
+A special notation "'<commit1>'..'<commit2>'" can be used as a
+short-hand for "^'<commit1>' '<commit2>'". For example, either of
+the following may be used interchangeably:
+
+ifdef::git-rev-list[]
+-----------------------------------------------------------------------
+$ git rev-list origin..HEAD
+$ git rev-list HEAD ^origin
+-----------------------------------------------------------------------
+endif::git-rev-list[]
+ifdef::git-log[]
+-----------------------------------------------------------------------
+$ git log origin..HEAD
+$ git log HEAD ^origin
+-----------------------------------------------------------------------
+endif::git-log[]
+
+Another special notation is "'<commit1>'...'<commit2>'" which is useful
+for merges. The resulting set of commits is the symmetric difference
+between the two operands. The following two commands are equivalent:
+
+ifdef::git-rev-list[]
+-----------------------------------------------------------------------
+$ git rev-list A B --not $(git merge-base --all A B)
+$ git rev-list A...B
+-----------------------------------------------------------------------
+endif::git-rev-list[]
+ifdef::git-log[]
+-----------------------------------------------------------------------
+$ git log A B --not $(git merge-base --all A B)
+$ git log A...B
+-----------------------------------------------------------------------
+endif::git-log[]
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index b01b2b6..0023790 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -128,8 +128,7 @@ parents) and `--max-parents=-1` (negative numbers denote no upper limit).
because merges into a topic branch tend to be only about
adjusting to updated upstream from time to time, and
this option allows you to ignore the individual commits
- brought in to your history by such a merge. Cannot be
- combined with --bisect.
+ brought in to your history by such a merge.
--not::
Reverses the meaning of the '{caret}' prefix (or lack thereof)
@@ -207,7 +206,7 @@ ifndef::git-rev-list[]
Pretend as if the bad bisection ref `refs/bisect/bad`
was listed and as if it was followed by `--not` and the good
bisection refs `refs/bisect/good-*` on the command
- line. Cannot be combined with --first-parent.
+ line.
endif::git-rev-list[]
--stdin::
@@ -743,7 +742,7 @@ outputs 'midpoint', the output of the two commands
would be of roughly the same length. Finding the change which
introduces a regression is thus reduced to a binary search: repeatedly
generate and test new 'midpoint's until the commit chain is of length
-one. Cannot be combined with --first-parent.
+one.
--bisect-vars::
This calculates the same as `--bisect`, except that refs in
@@ -1117,48 +1116,3 @@ ifdef::git-rev-list[]
by a tab.
endif::git-rev-list[]
endif::git-shortlog[]
-
-ifndef::git-shortlog[]
-ifndef::git-rev-list[]
-Diff Formatting
-~~~~~~~~~~~~~~~
-
-Listed below are options that control the formatting of diff output.
-Some of them are specific to linkgit:git-rev-list[1], however other diff
-options may be given. See linkgit:git-diff-files[1] for more options.
-
--c::
- With this option, diff output for a merge commit
- shows the differences from each of the parents to the merge result
- simultaneously instead of showing pairwise diff between a parent
- and the result one at a time. Furthermore, it lists only files
- which were modified from all parents.
-
---cc::
- This flag implies the `-c` option and further compresses the
- patch output by omitting uninteresting hunks whose contents in
- the parents have only two variants and the merge result picks
- one of them without modification.
-
---combined-all-paths::
- This flag causes combined diffs (used for merge commits) to
- list the name of the file from all parents. It thus only has
- effect when -c or --cc are specified, and is likely only
- useful if filename changes are detected (i.e. when either
- rename or copy detection have been requested).
-
--m::
- This flag makes the merge commits show the full diff like
- regular commits; for each merge parent, a separate log entry
- and diff is generated. An exception is that only diff against
- the first parent is shown when `--first-parent` option is given;
- in that case, the output represents the changes the merge
- brought _into_ the then-current branch.
-
--r::
- Show recursive diffs.
-
--t::
- Show the tree objects in the diff output. This implies `-r`.
-endif::git-rev-list[]
-endif::git-shortlog[]
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 1ad9506..d9169c0 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -254,6 +254,9 @@ 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.
diff --git a/Documentation/signoff-option.txt b/Documentation/signoff-option.txt
new file mode 100644
index 0000000..12aa233
--- /dev/null
+++ b/Documentation/signoff-option.txt
@@ -0,0 +1,18 @@
+ifdef::git-commit[]
+-s::
+endif::git-commit[]
+--signoff::
+--no-signoff::
+ Add a `Signed-off-by` trailer by the committer at the end of the commit
+ log message. The meaning of a signoff depends on the project
+ to which you're committing. For example, it may certify that
+ the committer has the rights to submit the work under the
+ project's license or agrees to some contributor representation,
+ such as a Developer Certificate of Origin.
+ (See http://developercertificate.org for the one used by the
+ Linux kernel and Git projects.) Consult the documentation or
+ leadership of the project to which you're contributing to
+ understand how the signoffs are used in that project.
++
+The --no-signoff option can be used to countermand an earlier --signoff
+option on the command line.
diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
index 2e2e7c1..5a60bbf 100644
--- a/Documentation/technical/api-parse-options.txt
+++ b/Documentation/technical/api-parse-options.txt
@@ -232,9 +232,9 @@ There are some macros to easily define options:
will be overwritten, so this should only be used for options where
the last one specified on the command line wins.
-`OPT_PASSTHRU_ARGV(short, long, &argv_array_var, arg_str, description, flags)`::
+`OPT_PASSTHRU_ARGV(short, long, &strvec_var, arg_str, description, flags)`::
Introduce an option where all instances of it on the command-line will
- be reconstructed into an argv_array. This is useful when you need to
+ be reconstructed into a strvec. This is useful when you need to
pass the command-line option, which can be specified multiple times,
to another command.
diff --git a/Documentation/technical/bundle-format.txt b/Documentation/technical/bundle-format.txt
index 0e82815..bac558d 100644
--- a/Documentation/technical/bundle-format.txt
+++ b/Documentation/technical/bundle-format.txt
@@ -7,6 +7,8 @@ The Git bundle format is a format that represents both refs and Git objects.
We will use ABNF notation to define the Git bundle format. See
protocol-common.txt for the details.
+A v2 bundle looks like this:
+
----
bundle = signature *prerequisite *reference LF pack
signature = "# v2 git bundle" LF
@@ -18,9 +20,28 @@ reference = obj-id SP refname LF
pack = ... ; packfile
----
+A v3 bundle looks like this:
+
+----
+bundle = signature *capability *prerequisite *reference LF pack
+signature = "# v3 git bundle" LF
+
+capability = "@" key ["=" value] LF
+prerequisite = "-" obj-id SP comment LF
+comment = *CHAR
+reference = obj-id SP refname LF
+key = 1*(ALPHA / DIGIT / "-")
+value = *(%01-09 / %0b-FF)
+
+pack = ... ; packfile
+----
+
== Semantics
-A Git bundle consists of three parts.
+A Git bundle consists of several parts.
+
+* "Capabilities", which are only in the v3 format, indicate functionality that
+ the bundle requires to be read properly.
* "Prerequisites" lists the objects that are NOT included in the bundle and the
reader of the bundle MUST already have, in order to use the data in the
@@ -46,3 +67,10 @@ put any string here. The reader of the bundle MUST ignore the comment.
Note that the prerequisites does not represent a shallow-clone boundary. The
semantics of the prerequisites and the shallow-clone boundaries are different,
and the Git bundle v2 format cannot represent a shallow clone repository.
+
+== Capabilities
+
+Because there is no opportunity for negotiation, unknown capabilities cause 'git
+bundle' to abort. The only known capability is `object-format`, which specifies
+the hash algorithm in use, and can take the same values as the
+`extensions.objectFormat` configuration value.
diff --git a/Documentation/technical/commit-graph-format.txt b/Documentation/technical/commit-graph-format.txt
index 1beef17..b3b5888 100644
--- a/Documentation/technical/commit-graph-format.txt
+++ b/Documentation/technical/commit-graph-format.txt
@@ -32,7 +32,7 @@ the body into "chunks" and provide a binary lookup table at the beginning
of the body. The header includes certain values, such as number of chunks
and hash type.
-All 4-byte numbers are in network order.
+All multi-byte numbers are in network byte order.
HEADER:
@@ -42,8 +42,13 @@ HEADER:
1-byte version number:
Currently, the only valid version is 1.
- 1-byte Hash Version (1 = SHA-1)
- We infer the hash length (H) from this value.
+ 1-byte Hash Version
+ We infer the hash length (H) from this value:
+ 1 => SHA-1
+ 2 => SHA-256
+ If the hash type does not match the repository's hash algorithm, the
+ commit-graph file should be ignored with a warning presented to the
+ user.
1-byte number (C) of "chunks"
@@ -77,7 +82,7 @@ CHUNK DATA:
Commit Data (ID: {'C', 'D', 'A', 'T' }) (N * (H + 16) bytes)
* The first H bytes are for the OID of the root tree.
* The next 8 bytes are for the positions of the first two parents
- of the ith commit. Stores value 0x7000000 if no parent in that
+ of the ith commit. Stores value 0x70000000 if no parent in that
position. If there are more than two parents, the second value
has its most-significant bit on and the other bits store an array
position into the Extra Edge List chunk.
@@ -120,7 +125,7 @@ CHUNK DATA:
* The rest of the chunk is the concatenation of all the computed Bloom
filters for the commits in lexicographic order.
* Note: Commits with no changes or more than 512 changes have Bloom filters
- of length zero.
+ of length one, with either all bits set to zero or one respectively.
* The BDAT chunk is present if and only if BIDX is present.
Base Graphs List (ID: {'B', 'A', 'S', 'E'}) [Optional]
diff --git a/Documentation/technical/commit-graph.txt b/Documentation/technical/commit-graph.txt
index 808fa30..f14a765 100644
--- a/Documentation/technical/commit-graph.txt
+++ b/Documentation/technical/commit-graph.txt
@@ -210,12 +210,12 @@ file.
+---------------------+
| |
+-----------------------+ +---------------------+
- | graph-{hash2} |->| |
+ | graph-{hash2} |->| |
+-----------------------+ +---------------------+
| | |
+-----------------------+ +---------------------+
| | | |
- | graph-{hash1} |->| |
+ | graph-{hash1} |->| |
| | | |
+-----------------------+ +---------------------+
| tmp_graphXXX
@@ -223,7 +223,7 @@ file.
| |
| |
| |
- | graph-{hash0} |
+ | graph-{hash0} |
| |
| |
| |
diff --git a/Documentation/technical/directory-rename-detection.txt b/Documentation/technical/directory-rename-detection.txt
index 844629c..49b83ef 100644
--- a/Documentation/technical/directory-rename-detection.txt
+++ b/Documentation/technical/directory-rename-detection.txt
@@ -18,7 +18,8 @@ It is perhaps easiest to start with an example:
More interesting possibilities exist, though, such as:
* one side of history renames x -> z, and the other renames some file to
- x/e, causing the need for the merge to do a transitive rename.
+ x/e, causing the need for the merge to do a transitive rename so that
+ the rename ends up at z/e.
* one side of history renames x -> z, but also renames all files within x.
For example, x/a -> z/alpha, x/b -> z/bravo, etc.
@@ -35,7 +36,7 @@ More interesting possibilities exist, though, such as:
directory itself contained inner directories that were renamed to yet
other locations).
- * combinations of the above; see t/t6043-merge-rename-directories.sh for
+ * combinations of the above; see t/t6423-merge-rename-directories.sh for
various interesting cases.
Limitations -- applicability of directory renames
@@ -62,19 +63,19 @@ directory rename detection applies:
Limitations -- detailed rules and testcases
-------------------------------------------
-t/t6043-merge-rename-directories.sh contains extensive tests and commentary
+t/t6423-merge-rename-directories.sh contains extensive tests and commentary
which generate and explore the rules listed above. It also lists a few
additional rules:
a) If renames split a directory into two or more others, the directory
with the most renames, "wins".
- b) Avoid directory-rename-detection for a path, if that path is the
- source of a rename on either side of a merge.
-
- c) Only apply implicit directory renames to directories if the other side
+ b) Only apply implicit directory renames to directories if the other side
of history is the one doing the renaming.
+ c) Do not perform directory rename detection for directories which had no
+ new paths added to them.
+
Limitations -- support in different commands
--------------------------------------------
diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt
index 5b2db3b..6fd20eb 100644
--- a/Documentation/technical/hash-function-transition.txt
+++ b/Documentation/technical/hash-function-transition.txt
@@ -650,7 +650,6 @@ Some initial steps can be implemented independently of one another:
The first user-visible change is the introduction of the objectFormat
extension (without compatObjectFormat). This requires:
-- implementing the loose-object-idx
- teaching fsck about this mode of operation
- using the hash function API (vtable) when computing object names
- signing objects and verifying signatures
@@ -658,6 +657,7 @@ extension (without compatObjectFormat). This requires:
repository
Next comes introduction of compatObjectFormat:
+- implementing the loose-object-idx
- translating object names between object formats
- translating object content between object formats
- generating and verifying signatures in the compat format
diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt
index 51a79e6..96d89ea 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -401,8 +401,9 @@ at all in the request stream:
The stream is terminated by a pkt-line flush (`0000`).
A single "want" or "have" command MUST have one hex formatted
-SHA-1 as its value. Multiple SHA-1s MUST be sent by sending
-multiple commands.
+object name as its value. Multiple object names MUST be sent by sending
+multiple commands. Object names MUST be given using the object format
+negotiated through the `object-format` capability (default SHA-1).
The `have` list is created by popping the first 32 commits
from `c_pending`. Less can be supplied if `c_pending` empties.
diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt
index faa25c5..f9a3644 100644
--- a/Documentation/technical/index-format.txt
+++ b/Documentation/technical/index-format.txt
@@ -3,8 +3,11 @@ Git index format
== The Git index file has the following format
- All binary numbers are in network byte order. Version 2 is described
- here unless stated otherwise.
+ All binary numbers are in network byte order.
+ In a repository using the traditional SHA-1, checksums and object IDs
+ (object names) mentioned below are all computed using SHA-1. Similarly,
+ in SHA-256 repositories, these values are computed using SHA-256.
+ Version 2 is described here unless stated otherwise.
- A 12-byte header consisting of
@@ -32,8 +35,7 @@ Git index format
Extension data
- - 160-bit SHA-1 over the content of the index file before this
- checksum.
+ - Hash checksum over the content of the index file before this checksum.
== Index entry
@@ -80,7 +82,7 @@ Git index format
32-bit file size
This is the on-disk size from stat(2), truncated to 32-bit.
- 160-bit SHA-1 for the represented object
+ Object name for the represented object
A 16-bit 'flags' field split into (high to low bits)
@@ -160,8 +162,8 @@ Git index format
- A newline (ASCII 10); and
- - 160-bit object name for the object that would result from writing
- this span of index as a tree.
+ - Object name for the object that would result from writing this span
+ of index as a tree.
An entry can be in an invalidated state and is represented by having
a negative number in the entry_count field. In this case, there is no
@@ -198,7 +200,7 @@ Git index format
stage 1 to 3 (a missing stage is represented by "0" in this field);
and
- - At most three 160-bit object names of the entry in stages from 1 to 3
+ - At most three object names of the entry in stages from 1 to 3
(nothing is written for a missing stage).
=== Split index
@@ -211,8 +213,8 @@ Git index format
The extension consists of:
- - 160-bit SHA-1 of the shared index file. The shared index file path
- is $GIT_DIR/sharedindex.<SHA-1>. If all 160 bits are zero, the
+ - Hash of the shared index file. The shared index file path
+ is $GIT_DIR/sharedindex.<hash>. If all bits are zero, the
index does not require a shared index file.
- An ewah-encoded delete bitmap, each bit represents an entry in the
@@ -253,10 +255,10 @@ Git index format
- 32-bit dir_flags (see struct dir_struct)
- - 160-bit SHA-1 of $GIT_DIR/info/exclude. Null SHA-1 means the file
+ - Hash of $GIT_DIR/info/exclude. A null hash means the file
does not exist.
- - 160-bit SHA-1 of core.excludesfile. Null SHA-1 means the file does
+ - Hash of core.excludesfile. A null hash means the file does
not exist.
- NUL-terminated string of per-dir exclude file name. This usually
@@ -285,13 +287,13 @@ The remaining data of each directory block is grouped by type:
- An ewah bitmap, the n-th bit records "check-only" bit of
read_directory_recursive() for the n-th directory.
- - An ewah bitmap, the n-th bit indicates whether SHA-1 and stat data
+ - An ewah bitmap, the n-th bit indicates whether hash and stat data
is valid for the n-th directory and exists in the next data.
- An array of stat data. The n-th data corresponds with the n-th
"one" bit in the previous ewah bitmap.
- - An array of SHA-1. The n-th SHA-1 corresponds with the n-th "one" bit
+ - An array of hashes. The n-th hash corresponds with the n-th "one" bit
in the previous ewah bitmap.
- One NUL.
@@ -330,12 +332,12 @@ The remaining data of each directory block is grouped by type:
- 32-bit offset to the end of the index entries
- - 160-bit SHA-1 over the extension types and their sizes (but not
+ - Hash over the extension types and their sizes (but not
their contents). E.g. if we have "TREE" extension that is N-bytes
long, "REUC" extension that is M-bytes long, followed by "EOIE",
then the hash would be:
- SHA-1("TREE" + <binary representation of N> +
+ Hash("TREE" + <binary representation of N> +
"REUC" + <binary representation of M>)
== Index Entry Offset Table
diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt
index d3a142c..f96b2e6 100644
--- a/Documentation/technical/pack-format.txt
+++ b/Documentation/technical/pack-format.txt
@@ -1,6 +1,12 @@
Git pack format
===============
+== Checksums and object IDs
+
+In a repository using the traditional SHA-1, pack checksums, index checksums,
+and object IDs (object names) mentioned below are all computed using SHA-1.
+Similarly, in SHA-256 repositories, these values are computed using SHA-256.
+
== pack-*.pack files have the following format:
- A header appears at the beginning and consists of the following:
@@ -26,7 +32,7 @@ Git pack format
(deltified representation)
n-byte type and length (3-bit type, (n-1)*7+4-bit length)
- 20-byte base object name if OBJ_REF_DELTA or a negative relative
+ base object name if OBJ_REF_DELTA or a negative relative
offset from the delta object's position in the pack if this
is an OBJ_OFS_DELTA object
compressed delta data
@@ -34,7 +40,7 @@ Git pack format
Observation: length of each object is encoded in a variable
length format and is not constrained to 32-bit or anything.
- - The trailer records 20-byte SHA-1 checksum of all of the above.
+ - The trailer records a pack checksum of all of the above.
=== Object types
@@ -58,8 +64,8 @@ ofs-delta and ref-delta, which is only valid in a pack file.
Both ofs-delta and ref-delta store the "delta" to be applied to
another object (called 'base object') to reconstruct the object. The
-difference between them is, ref-delta directly encodes 20-byte base
-object name. If the base object is in the same pack, ofs-delta encodes
+difference between them is, ref-delta directly encodes base object
+name. If the base object is in the same pack, ofs-delta encodes
the offset of the base object in the pack instead.
The base object could also be deltified if it's in the same pack.
@@ -143,14 +149,14 @@ This is the instruction reserved for future expansion.
object is stored in the packfile as the offset from the
beginning.
- 20-byte object name.
+ one object name of the appropriate size.
- The file is concluded with a trailer:
- A copy of the 20-byte SHA-1 checksum at the end of
- corresponding packfile.
+ A copy of the pack checksum at the end of the corresponding
+ packfile.
- 20-byte SHA-1-checksum of all of the above.
+ Index checksum of all of the above.
Pack Idx file:
@@ -198,7 +204,7 @@ Pack file entry: <+
If it is not DELTA, then deflated bytes (the size above
is the size before compression).
If it is REF_DELTA, then
- 20-byte base object name SHA-1 (the size above is the
+ base object name (the size above is the
size of the delta data that follows).
delta data, deflated.
If it is OFS_DELTA, then
@@ -227,9 +233,9 @@ Pack file entry: <+
- A 256-entry fan-out table just like v1.
- - A table of sorted 20-byte SHA-1 object names. These are
- packed together without offset values to reduce the cache
- footprint of the binary search for a specific object name.
+ - A table of sorted object names. These are packed together
+ without offset values to reduce the cache footprint of the
+ binary search for a specific object name.
- A table of 4-byte CRC32 values of the packed object data.
This is new in v2 so compressed data can be copied directly
@@ -248,10 +254,10 @@ Pack file entry: <+
- The same trailer as a v1 pack file:
- A copy of the 20-byte SHA-1 checksum at the end of
+ A copy of the pack checksum at the end of
corresponding packfile.
- 20-byte SHA-1-checksum of all of the above.
+ Index checksum of all of the above.
== multi-pack-index (MIDX) files have the following format:
@@ -273,7 +279,12 @@ HEADER:
Git only writes or recognizes version 1.
1-byte Object Id Version
- Git only writes or recognizes version 1 (SHA1).
+ We infer the length of object IDs (OIDs) from this value:
+ 1 => SHA-1
+ 2 => SHA-256
+ If the hash type does not match the repository's hash algorithm,
+ the multi-pack-index file should be ignored with a warning
+ presented to the user.
1-byte number of "chunks"
@@ -329,4 +340,4 @@ CHUNK DATA:
TRAILER:
- 20-byte SHA1-checksum of the above contents.
+ Index checksum of the above contents.
diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt
index a4573d1..e13a2c0 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -503,8 +503,8 @@ The reference discovery phase is done nearly the same way as it is in the
fetching protocol. Each reference obj-id and name on the server is sent
in packet-line format to the client, followed by a flush-pkt. The only
real difference is that the capability listing is different - the only
-possible values are 'report-status', 'delete-refs', 'ofs-delta' and
-'push-options'.
+possible values are 'report-status', 'report-status-v2', 'delete-refs',
+'ofs-delta', 'atomic' and 'push-options'.
Reference Update Request and Packfile Transfer
----------------------------------------------
@@ -625,7 +625,7 @@ Report Status
-------------
After receiving the pack data from the sender, the receiver sends a
-report if 'report-status' capability is in effect.
+report if 'report-status' or 'report-status-v2' capability is in effect.
It is a short listing of what happened in that update. It will first
list the status of the packfile unpacking as either 'unpack ok' or
'unpack [error]'. Then it will list the status for each of the references
@@ -647,6 +647,41 @@ update was successful, or 'ng [refname] [error]' if the update was not.
error-msg = 1*(OCTET) ; where not "ok"
----
+The 'report-status-v2' capability extends the protocol by adding new option
+lines in order to support reporting of reference rewritten by the
+'proc-receive' hook. The 'proc-receive' hook may handle a command for a
+pseudo-reference which may create or update one or more references, and each
+reference may have different name, different new-oid, and different old-oid.
+
+----
+ report-status-v2 = unpack-status
+ 1*(command-status-v2)
+ flush-pkt
+
+ unpack-status = PKT-LINE("unpack" SP unpack-result)
+ unpack-result = "ok" / error-msg
+
+ command-status-v2 = command-ok-v2 / command-fail
+ command-ok-v2 = command-ok
+ *option-line
+
+ command-ok = PKT-LINE("ok" SP refname)
+ command-fail = PKT-LINE("ng" SP refname SP error-msg)
+
+ error-msg = 1*(OCTET) ; where not "ok"
+
+ option-line = *1(option-refname)
+ *1(option-old-oid)
+ *1(option-new-oid)
+ *1(option-forced-update)
+
+ option-refname = PKT-LINE("option" SP "refname" SP refname)
+ option-old-oid = PKT-LINE("option" SP "old-oid" SP obj-id)
+ option-new-oid = PKT-LINE("option" SP "new-oid" SP obj-id)
+ option-force = PKT-LINE("option" SP "forced-update")
+
+----
+
Updates can be unsuccessful for a number of reasons. The reference can have
changed since the reference discovery phase was originally sent, meaning
someone pushed in the meantime. The reference being pushed could be a
diff --git a/Documentation/technical/partial-clone.txt b/Documentation/technical/partial-clone.txt
index b9e17e7..0780d30 100644
--- a/Documentation/technical/partial-clone.txt
+++ b/Documentation/technical/partial-clone.txt
@@ -171,20 +171,13 @@ additional flag.
Fetching Missing Objects
------------------------
-- Fetching of objects is done using the existing transport mechanism using
- transport_fetch_refs(), setting a new transport option
- TRANS_OPT_NO_DEPENDENTS to indicate that only the objects themselves are
- desired, not any object that they refer to.
-+
-Because some transports invoke fetch_pack() in the same process, fetch_pack()
-has been updated to not use any object flags when the corresponding argument
-(no_dependents) is set.
+- Fetching of objects is done by invoking a "git fetch" subprocess.
- The local repository sends a request with the hashes of all requested
- objects as "want" lines, and does not perform any packfile negotiation.
+ objects, and does not perform any packfile negotiation.
It then receives a packfile.
-- Because we are reusing the existing fetch-pack mechanism, fetching
+- Because we are reusing the existing fetch mechanism, fetching
currently fetches all objects referred to by the requested objects, even
though they are not necessary.
diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt
index 36ccd14..ba869a7 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -22,9 +22,9 @@ was sent. Server MUST NOT ignore capabilities that client requested
and server advertised. As a consequence of these rules, server MUST
NOT advertise capabilities it does not understand.
-The 'atomic', 'report-status', 'delete-refs', 'quiet', and 'push-cert'
-capabilities are sent and recognized by the receive-pack (push to server)
-process.
+The 'atomic', 'report-status', 'report-status-v2', 'delete-refs', 'quiet',
+and 'push-cert' capabilities are sent and recognized by the receive-pack
+(push to server) process.
The 'ofs-delta' and 'side-band-64k' capabilities are sent and recognized
by both upload-pack and receive-pack protocols. The 'agent' capability
@@ -284,6 +284,17 @@ each reference was updated successfully. If any of those were not
successful, it will send back an error message. See pack-protocol.txt
for example messages.
+report-status-v2
+----------------
+
+Capability 'report-status-v2' extends capability 'report-status' by
+adding new "option" directives in order to support reference rewritten by
+the "proc-receive" hook. The "proc-receive" hook may handle a command
+for a pseudo-reference which may create or update a reference with
+different name, new-oid, and old-oid. While the capability
+'report-status' cannot report for such case. See pack-protocol.txt
+for details.
+
delete-refs
-----------
@@ -324,15 +335,19 @@ allow-tip-sha1-in-want
----------------------
If the upload-pack server advertises this capability, fetch-pack may
-send "want" lines with SHA-1s that exist at the server but are not
-advertised by upload-pack.
+send "want" lines with object names that exist at the server but are not
+advertised by upload-pack. For historical reasons, the name of this
+capability contains "sha1". Object names are always given using the
+object format negotiated through the 'object-format' capability.
allow-reachable-sha1-in-want
----------------------------
If the upload-pack server advertises this capability, fetch-pack may
-send "want" lines with SHA-1s that exist at the server but are not
-advertised by upload-pack.
+send "want" lines with object names that exist at the server but are not
+advertised by upload-pack. For historical reasons, the name of this
+capability contains "sha1". Object names are always given using the
+object format negotiated through the 'object-format' capability.
push-cert=<nonce>
-----------------
diff --git a/Documentation/technical/shallow.txt b/Documentation/technical/shallow.txt
index 01dedfe..f3738ba 100644
--- a/Documentation/technical/shallow.txt
+++ b/Documentation/technical/shallow.txt
@@ -13,7 +13,7 @@ pretend as if they are root commits (e.g. "git log" traversal
stops after showing them; "git fsck" does not complain saying
the commits listed on their "parent" lines do not exist).
-Each line contains exactly one SHA-1. When read, a commit_graft
+Each line contains exactly one object name. When read, a commit_graft
will be constructed, which has nr_parent < 0 to make it easier
to discern from user provided grafts.