Merge branch 'ds/include-exclude'
authorJunio C Hamano <gitster@pobox.com>
Mon, 30 Sep 2019 04:19:31 +0000 (13:19 +0900)
committerJunio C Hamano <gitster@pobox.com>
Mon, 30 Sep 2019 04:19:32 +0000 (13:19 +0900)
The internal code originally invented for ".gitignore" processing
got reshuffled and renamed to make it less tied to "excluding" and
stress more that it is about "matching", as it has been reused for
things like sparse checkout specification that want to check if a
path is "included".

* ds/include-exclude:
  unpack-trees: rename 'is_excluded_from_list()'
  treewide: rename 'exclude' methods to 'pattern'
  treewide: rename 'EXCL_FLAG_' to 'PATTERN_FLAG_'
  treewide: rename 'struct exclude_list' to 'struct pattern_list'
  treewide: rename 'struct exclude' to 'struct path_pattern'

509 files changed:
.gitattributes
.gitignore
.mailmap
.travis.yml
Documentation/CodingGuidelines
Documentation/MyFirstContribution.txt
Documentation/RelNotes/2.22.1.txt [new file with mode: 0644]
Documentation/RelNotes/2.23.0.txt
Documentation/RelNotes/2.24.0.txt [new file with mode: 0644]
Documentation/blame-options.txt
Documentation/config.txt
Documentation/config/advice.txt
Documentation/config/alias.txt
Documentation/config/blame.txt
Documentation/config/branch.txt
Documentation/config/checkout.txt
Documentation/config/color.txt
Documentation/config/core.txt
Documentation/config/diff.txt
Documentation/config/feature.txt [new file with mode: 0644]
Documentation/config/fetch.txt
Documentation/config/format.txt
Documentation/config/gc.txt
Documentation/config/gpg.txt
Documentation/config/index.txt
Documentation/config/interactive.txt
Documentation/config/log.txt
Documentation/config/pack.txt
Documentation/config/remote.txt
Documentation/config/stash.txt
Documentation/config/status.txt
Documentation/config/tag.txt
Documentation/config/transfer.txt
Documentation/fetch-options.txt
Documentation/git-blame.txt
Documentation/git-branch.txt
Documentation/git-check-ref-format.txt
Documentation/git-checkout.txt
Documentation/git-cherry-pick.txt
Documentation/git-clean.txt
Documentation/git-clone.txt
Documentation/git-commit-graph.txt
Documentation/git-commit.txt
Documentation/git-cvsserver.txt
Documentation/git-fast-export.txt
Documentation/git-fast-import.txt
Documentation/git-fetch.txt
Documentation/git-filter-branch.txt
Documentation/git-for-each-ref.txt
Documentation/git-format-patch.txt
Documentation/git-fsck.txt
Documentation/git-gc.txt
Documentation/git-log.txt
Documentation/git-merge-base.txt
Documentation/git-merge.txt
Documentation/git-multi-pack-index.txt
Documentation/git-pack-objects.txt
Documentation/git-pull.txt
Documentation/git-push.txt
Documentation/git-rebase.txt
Documentation/git-remote.txt
Documentation/git-repack.txt
Documentation/git-replace.txt
Documentation/git-rerere.txt
Documentation/git-reset.txt
Documentation/git-restore.txt [new file with mode: 0644]
Documentation/git-rev-list.txt
Documentation/git-revert.txt
Documentation/git-stash.txt
Documentation/git-svn.txt
Documentation/git-switch.txt [new file with mode: 0644]
Documentation/git-tag.txt
Documentation/git.txt
Documentation/gitattributes.txt
Documentation/gitcli.txt
Documentation/gitcore-tutorial.txt
Documentation/giteveryday.txt
Documentation/githooks.txt
Documentation/gitremote-helpers.txt
Documentation/gitrepository-layout.txt
Documentation/gittutorial-2.txt
Documentation/gittutorial.txt
Documentation/gitweb.txt
Documentation/gitworkflows.txt
Documentation/glossary-content.txt
Documentation/merge-options.txt
Documentation/rev-list-options.txt
Documentation/revisions.txt
Documentation/sequencer.txt
Documentation/technical/api-ref-iteration.txt
Documentation/technical/api-trace2.txt
Documentation/technical/api-tree-walking.txt
Documentation/technical/commit-graph-format.txt
Documentation/technical/commit-graph.txt
Documentation/technical/hash-function-transition.txt
Documentation/technical/partial-clone.txt
Documentation/technical/protocol-v2.txt
Documentation/user-manual.txt
GIT-VERSION-GEN
Makefile
README.md
RelNotes
advice.c
advice.h
apply.c
apply.h
archive-tar.c
archive.c
banned.h
blame.c
blame.h
blob.c
branch.c
branch.h
builtin.h
builtin/am.c
builtin/blame.c
builtin/branch.c
builtin/cat-file.c
builtin/checkout.c
builtin/clean.c
builtin/clone.c
builtin/commit-graph.c
builtin/commit.c
builtin/describe.c
builtin/env--helper.c [new file with mode: 0644]
builtin/fast-export.c
builtin/fetch.c
builtin/fsck.c
builtin/gc.c
builtin/grep.c
builtin/index-pack.c
builtin/interpret-trailers.c
builtin/log.c
builtin/ls-files.c
builtin/merge-tree.c
builtin/merge.c
builtin/multi-pack-index.c
builtin/name-rev.c
builtin/pack-objects.c
builtin/prune.c
builtin/pull.c
builtin/push.c
builtin/rebase.c
builtin/receive-pack.c
builtin/repack.c
builtin/replace.c
builtin/reset.c
builtin/rev-list.c
builtin/revert.c
builtin/rm.c
builtin/stash.c
builtin/submodule--helper.c
builtin/tag.c
builtin/unpack-objects.c
builtin/update-index.c
builtin/verify-commit.c
builtin/verify-tag.c
builtin/worktree.c
bulk-checkin.c
cache-tree.c
cache.h
ci/install-dependencies.sh
ci/lib.sh
ci/run-build-and-tests.sh
command-list.txt
commit-graph.c
commit-graph.h
commit.c
common-main.c
compat/mingw.c
compat/mingw.h
compat/msvc.h
compat/nedmalloc/malloc.c.h
compat/obstack.h
compat/poll/poll.c
compat/vcbuild/.gitignore [new file with mode: 0644]
compat/vcbuild/README
compat/vcbuild/find_vs_env.bat [new file with mode: 0644]
compat/vcbuild/scripts/clink.pl
compat/vcbuild/vcpkg_copy_dlls.bat [new file with mode: 0644]
compat/vcbuild/vcpkg_install.bat [new file with mode: 0644]
compat/win32/git.manifest [new file with mode: 0644]
compat/win32/pthread.h
compat/winansi.c
config.c
config.mak.uname
configure.ac
connect.c
connected.c
contrib/buildsystems/Generators.pm
contrib/buildsystems/Generators/Vcproj.pm
contrib/buildsystems/Generators/Vcxproj.pm [new file with mode: 0644]
contrib/buildsystems/engine.pl
contrib/coccinelle/array.cocci
contrib/completion/git-completion.bash
contrib/completion/git-prompt.sh
contrib/svn-fe/svn-fe.txt
convert.c
convert.h
decorate.c
delta-islands.c
delta-islands.h
diff-delta.c
diff.c
diff.h
diffcore-rename.c
dir-iterator.c
dir-iterator.h
dir.c
editor.c
environment.c
fast-import.c
fetch-negotiator.c
fetch-negotiator.h
fetch-object.c [deleted file]
fetch-object.h [deleted file]
fetch-pack.c
fsck.c
fsmonitor.c
gettext.c
git-add--interactive.perl
git-compat-util.h
git-filter-branch.sh
git-gui/git-gui.sh
git-gui/lib/checkout_op.tcl
git-gui/lib/commit.tcl
git-gui/lib/diff.tcl
git-gui/lib/index.tcl
git-mergetool.sh
git-p4.py
git-sh-i18n.sh
git.c
git.rc
gitk-git/gitk
gitk-git/po/zh_cn.po [new file with mode: 0644]
gpg-interface.c
grep.c
hash.h
hashmap.h
help.c
help.h
http-push.c
http.c
http.h
khash.h
kwset.c
line-log.c
list-objects-filter-options.c
list-objects-filter-options.h
ll-merge.c
ll-merge.h
log-tree.c
match-trees.c
merge-recursive.c
midx.c
midx.h
name-hash.c
notes.c
object-store.h
object.c
object.h
oidmap.c
oidset.c
oidset.h
pack-bitmap-write.c
pack-bitmap.c
pack-bitmap.h
pack-objects.c
pack-objects.h
packfile.c
packfile.h
pager.c
parse-options-cb.c
parse-options.c
parse-options.h
patch-ids.c
path.c
path.h
po/README
po/bg.po
po/ca.po
po/de.po
po/es.po
po/fr.po
po/git.pot
po/it.po
po/ru.po
po/sv.po
po/vi.po
po/zh_CN.po
pretty.c
progress.c
promisor-remote.c [new file with mode: 0644]
promisor-remote.h [new file with mode: 0644]
quote.c
quote.h
range-diff.c
reachable.c
read-cache.c
ref-filter.c
refs.c
refs/files-backend.c
refs/packed-backend.c
repo-settings.c [new file with mode: 0644]
repository.h
revision.c
sequencer.c
sequencer.h
setup.c
sh-i18n--envsubst.c
sha1-file.c
sha1-name.c
shallow.c
strbuf.c
strbuf.h
t/README
t/helper/test-dir-iterator.c [new file with mode: 0644]
t/helper/test-example-decorate.c
t/helper/test-hashmap.c
t/helper/test-match-trees.c
t/helper/test-oidmap.c [new file with mode: 0644]
t/helper/test-read-cache.c
t/helper/test-tool.c
t/helper/test-tool.h
t/lib-git-daemon.sh
t/lib-git-svn.sh
t/lib-httpd.sh
t/lib-patch-mode.sh
t/lib-rebase.sh
t/perf/p5601-clone-reference.sh [new file with mode: 0755]
t/t0000-basic.sh
t/t0001-init.sh
t/t0007-git-var.sh
t/t0011-hashmap.sh
t/t0016-oidmap.sh [new file with mode: 0755]
t/t0017-env-helper.sh [new file with mode: 0755]
t/t0021-conversion.sh
t/t0027-auto-crlf.sh
t/t0040-parse-options.sh
t/t0061-run-command.sh
t/t0066-dir-iterator.sh [new file with mode: 0755]
t/t0090-cache-tree.sh
t/t0205-gettext-poison.sh
t/t0211-trace2-perf.sh
t/t0410-partial-clone.sh
t/t1007-hash-object.sh
t/t1090-sparse-checkout-scope.sh
t/t1300-config.sh
t/t1305-config-include.sh
t/t1309-early-config.sh
t/t1404-update-ref-errors.sh
t/t1410-reflog.sh
t/t1414-reflog-walk.sh
t/t1450-fsck.sh
t/t1506-rev-parse-diagnosis.sh
t/t1507-rev-parse-upstream.sh
t/t1600-index.sh
t/t1700-split-index.sh
t/t2014-checkout-switch.sh [moved from t/t2014-switch.sh with 100% similarity]
t/t2020-checkout-detach.sh
t/t2022-checkout-paths.sh
t/t2060-switch.sh [new file with mode: 0755]
t/t2070-restore.sh [new file with mode: 0755]
t/t2071-restore-patch.sh [new file with mode: 0755]
t/t2203-add-intent.sh
t/t3005-ls-files-relative.sh
t/t3200-branch.sh
t/t3201-branch-contains.sh
t/t3203-branch-output.sh
t/t3206-range-diff.sh
t/t3206/history.export
t/t3301-notes.sh
t/t3305-notes-fanout.sh
t/t3306-notes-prune.sh
t/t3311-notes-merge-fanout.sh
t/t3400-rebase.sh
t/t3404-rebase-interactive.sh
t/t3416-rebase-onto-threedots.sh
t/t3418-rebase-continue.sh
t/t3420-rebase-autostash.sh
t/t3421-rebase-topology-linear.sh
t/t3422-rebase-incompatible-options.sh
t/t3427-rebase-subtree.sh
t/t3430-rebase-merges.sh
t/t3431-rebase-fork-point.sh [new file with mode: 0755]
t/t3432-rebase-fast-forward.sh [new file with mode: 0755]
t/t3506-cherry-pick-ff.sh
t/t3510-cherry-pick-sequence.sh
t/t3600-rm.sh
t/t3701-add-interactive.sh
t/t3800-mktag.sh
t/t3903-stash.sh
t/t4000-diff-format.sh
t/t4002-diff-basic.sh
t/t4009-diff-rename-4.sh
t/t4013-diff-various.sh
t/t4014-format-patch.sh
t/t4015-diff-whitespace.sh
t/t4018-diff-funcname.sh
t/t4018/dts-labels [new file with mode: 0644]
t/t4018/dts-node-unitless [new file with mode: 0644]
t/t4018/dts-nodes [new file with mode: 0644]
t/t4018/dts-nodes-comment1 [new file with mode: 0644]
t/t4018/dts-nodes-comment2 [new file with mode: 0644]
t/t4018/dts-reference [new file with mode: 0644]
t/t4018/dts-root [new file with mode: 0644]
t/t4034-diff-words.sh
t/t4034/dts/expect [new file with mode: 0644]
t/t4034/dts/post [new file with mode: 0644]
t/t4034/dts/pre [new file with mode: 0644]
t/t4067-diff-partial-clone.sh
t/t4150-am.sh
t/t4202-log.sh
t/t4203-mailmap.sh
t/t4211-line-log.sh
t/t5000-tar-tree.sh
t/t5000/huge-object [moved from t/t5000/19f9c8273ec45a8938e6999cb59b3ff66739902a with 100% similarity]
t/t5004-archive-corner-cases.sh
t/t5307-pack-missing-commit.sh
t/t5310-pack-bitmaps.sh
t/t5318-commit-graph.sh
t/t5319-multi-pack-index.sh
t/t5324-split-commit-graph.sh [new file with mode: 0755]
t/t5500-fetch-pack.sh
t/t5504-fetch-receive-strict.sh
t/t5510-fetch.sh
t/t5512-ls-remote.sh
t/t5514-fetch-multiple.sh
t/t5515-fetch-merge-logic.sh
t/t5517-push-mirror.sh
t/t5537-fetch-shallow.sh
t/t5541-http-push-smart.sh
t/t5545-push-options.sh
t/t5551-http-fetch-smart.sh
t/t5552-skipping-fetch-negotiator.sh
t/t5553-set-upstream.sh [new file with mode: 0755]
t/t5601-clone.sh
t/t5604-clone-reference.sh
t/t5607-clone-bundle.sh
t/t5616-partial-clone.sh
t/t5618-alternate-refs.sh [new file with mode: 0755]
t/t5700-protocol-v1.sh
t/t5702-protocol-v2.sh
t/t5703-upload-pack-ref-in-want.sh
t/t5801-remote-helpers.sh
t/t5801/git-remote-testgit
t/t6000-rev-list-misc.sh
t/t6006-rev-list-format.sh
t/t6011-rev-list-with-bad-commit.sh
t/t6030-bisect-porcelain.sh
t/t6040-tracking-info.sh
t/t6043-merge-rename-directories.sh
t/t6200-fmt-merge-msg.sh
t/t6300-for-each-ref.sh
t/t6302-for-each-ref-filter.sh
t/t6501-freshen-objects.sh
t/t7004-tag.sh
t/t7060-wtstatus.sh
t/t7064-wtstatus-pv2.sh
t/t7201-co.sh
t/t7300-clean.sh
t/t7406-submodule-update.sh
t/t7407-submodule-foreach.sh
t/t7502-commit-porcelain.sh
t/t7503-pre-commit-and-pre-merge-commit-hooks.sh [new file with mode: 0755]
t/t7503-pre-commit-hook.sh [deleted file]
t/t7508-status.sh
t/t7512-status-help.sh
t/t7513-interpret-trailers.sh
t/t7610-mergetool.sh
t/t7700-repack.sh
t/t7814-grep-recurse-submodules.sh
t/t8003-blame-corner-cases.sh
t/t8013-blame-ignore-revs.sh [new file with mode: 0755]
t/t8014-blame-ignore-fuzzy.sh [new file with mode: 0755]
t/t9801-git-p4-branch.sh
t/t9817-git-p4-exclude.sh
t/t9902-completion.sh
t/t9903-bash-prompt.sh
t/test-lib-functions.sh
t/test-lib.sh
tag.c
tag.h
templates/hooks--pre-merge-commit.sample [new file with mode: 0755]
trace.c
trace2/tr2_dst.c
trace2/tr2_tgt_event.c
trace2/tr2_tgt_normal.c
trace2/tr2_tgt_perf.c
transport-helper.c
transport-internal.h
transport.c
transport.h
tree-diff.c
tree-walk.c
tree-walk.h
tree.c
unpack-trees.c
upload-pack.c
userdiff.c
walker.c
wrapper.c
wt-status.c
wt-status.h
xdiff/xemit.c
xdiff/xhistogram.c
xdiff/xpatience.c
xdiff/xutils.c

index 9fa72ad..b08a141 100644 (file)
@@ -5,6 +5,7 @@
 *.pl eof=lf diff=perl
 *.pm eol=lf diff=perl
 *.py eol=lf diff=python
+*.bat eol=crlf
 /Documentation/**/*.txt eol=lf
 /command-list.txt eol=lf
 /GIT-VERSION-GEN eol=lf
index 4470d7c..fc445ed 100644 (file)
@@ -58,6 +58,7 @@
 /git-difftool
 /git-difftool--helper
 /git-describe
+/git-env--helper
 /git-fast-export
 /git-fast-import
 /git-fetch
 /git-request-pull
 /git-rerere
 /git-reset
+/git-restore
 /git-rev-list
 /git-rev-parse
 /git-revert
 /git-submodule
 /git-submodule--helper
 /git-svn
+/git-switch
 /git-symbolic-ref
 /git-tag
 /git-unpack-file
 *.user
 *.idb
 *.pdb
-/Debug/
-/Release/
+*.ilk
+*.iobj
+*.ipdb
+*.dll
+.vs/
+Debug/
+Release/
+/UpgradeLog*.htm
+/git.VC.VC.opendb
+/git.VC.db
 *.dSYM
index 82cd056..9a5ff04 100644 (file)
--- a/.mailmap
+++ b/.mailmap
@@ -210,6 +210,7 @@ Petr Baudis <pasky@ucw.cz> <pasky@suse.cz>
 Petr Baudis <pasky@ucw.cz> <xpasky@machine>
 Phil Hord <hordp@cisco.com> <phil.hord@gmail.com>
 Philip J├Ągenstedt <philip@foolip.org> <philip.jagenstedt@gmail.com>
+Philip Oakley <philipoakley@iee.email> <philipoakley@iee.org> # secondary <philipoakley@dunelm.org.uk>
 Philipp A. Hartmann <pah@qo.cx> <ph@sorgh.de>
 Philippe Bruhat <book@cpan.org>
 Ralf Thielow <ralf.thielow@gmail.com> <ralf.thielow@googlemail.com>
index ffb1bc4..fc5730b 100644 (file)
@@ -21,6 +21,10 @@ matrix:
       compiler:
       addons:
       before_install:
+    - env: jobname=linux-gcc-4.8
+      os: linux
+      dist: trusty
+      compiler:
     - env: jobname=Linux32
       os: linux
       compiler:
index 1169ff6..f45db5b 100644 (file)
@@ -195,10 +195,30 @@ For C programs:
    by e.g. "echo DEVELOPER=1 >>config.mak".
 
  - We try to support a wide range of C compilers to compile Git with,
-   including old ones. That means that you should not use C99
-   initializers, even if a lot of compilers grok it.
+   including old ones.  You should not use features from newer C
+   standard, even if your compiler groks them.
 
- - Variables have to be declared at the beginning of the block.
+   There are a few exceptions to this guideline:
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifer at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   These used to be forbidden, but we have not heard any breakage
+   report, and they are assumed to be safe.
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - Declaring a variable in the for loop "for (int i = 0; i < 10; i++)"
+   is still not allowed in this codebase.
 
  - NULL pointers shall be written as NULL, not as 0.
 
index 895b7cf..f867037 100644 (file)
@@ -428,7 +428,7 @@ git-psuh - Delight users' typo with a shy horse
 SYNOPSIS
 --------
 [verse]
-'git-psuh'
+'git-psuh [<arg>...]'
 
 DESCRIPTION
 -----------
@@ -491,14 +491,16 @@ Take a look at `Documentation/technical/api-parse-options.txt`. This is a handy
 tool for pulling out options you need to be able to handle, and it takes a
 usage string.
 
-In order to use it, we'll need to prepare a NULL-terminated usage string and a
-`builtin_psuh_options` array. Add a line to `#include "parse-options.h"`.
+In order to use it, we'll need to prepare a NULL-terminated array of usage
+strings and a `builtin_psuh_options` array.
 
-At global scope, add your usage:
+Add a line to `#include "parse-options.h"`.
+
+At global scope, add your array of usage strings:
 
 ----
 static const char * const psuh_usage[] = {
-       N_("git psuh"),
+       N_("git psuh [<arg>...]"),
        NULL,
 };
 ----
diff --git a/Documentation/RelNotes/2.22.1.txt b/Documentation/RelNotes/2.22.1.txt
new file mode 100644 (file)
index 0000000..432762f
--- /dev/null
@@ -0,0 +1,150 @@
+Git 2.22.1 Release Notes
+========================
+
+Fixes since v2.22
+-----------------
+
+ * A relative pathname given to "git init --template=<path> <repo>"
+   ought to be relative to the directory "git init" gets invoked in,
+   but it instead was made relative to the repository, which has been
+   corrected.
+
+ * "git worktree add" used to fail when another worktree connected to
+   the same repository was corrupt, which has been corrected.
+
+ * The ownership rule for the file descriptor to fast-import remote
+   backend was mixed up, leading to unrelated file descriptor getting
+   closed, which has been fixed.
+
+ * "git update-server-info" used to leave stale packfiles in its
+   output, which has been corrected.
+
+ * The server side support for "git fetch" used to show incorrect
+   value for the HEAD symbolic ref when the namespace feature is in
+   use, which has been corrected.
+
+ * "git am -i --resolved" segfaulted after trying to see a commit as
+   if it were a tree, which has been corrected.
+
+ * "git bundle verify" needs to see if prerequisite objects exist in
+   the receiving repository, but the command did not check if we are
+   in a repository upfront, which has been corrected.
+
+ * "git merge --squash" is designed to update the working tree and the
+   index without creating the commit, and this cannot be countermanded
+   by adding the "--commit" option; the command now refuses to work
+   when both options are given.
+
+ * The data collected by fsmonitor was not properly written back to
+   the on-disk index file, breaking t7519 tests occasionally, which
+   has been corrected.
+
+ * Update to Unicode 12.1 width table.
+
+ * The command line to invoke a "git cat-file" command from inside
+   "git p4" was not properly quoted to protect a caret and running a
+   broken command on Windows, which has been corrected.
+
+ * "git request-pull" learned to warn when the ref we ask them to pull
+   from in the local repository and in the published repository are
+   different.
+
+ * When creating a partial clone, the object filtering criteria is
+   recorded for the origin of the clone, but this incorrectly used a
+   hardcoded name "origin" to name that remote; it has been corrected
+   to honor the "--origin <name>" option.
+
+ * "git fetch" into a lazy clone forgot to fetch base objects that are
+   necessary to complete delta in a thin packfile, which has been
+   corrected.
+
+ * The filter_data used in the list-objects-filter (which manages a
+   lazily sparse clone repository) did not use the dynamic array API
+   correctly---'nr' is supposed to point at one past the last element
+   of the array in use.  This has been corrected.
+
+ * The description about slashes in gitignore patterns (used to
+   indicate things like "anchored to this level only" and "only
+   matches directories") has been revamped.
+
+ * The URL decoding code has been updated to avoid going past the end
+   of the string while parsing %-<hex>-<hex> sequence.
+
+ * The list of for-each like macros used by clang-format has been
+   updated.
+
+ * "git push --atomic" that goes over the transport-helper (namely,
+   the smart http transport) failed to prevent refs to be pushed when
+   it can locally tell that one of the ref update will fail without
+   having to consult the other end, which has been corrected.
+
+ * "git clean" silently skipped a path when it cannot lstat() it; now
+   it gives a warning.
+
+ * A codepath that reads from GPG for signed object verification read
+   past the end of allocated buffer, which has been fixed.
+
+ * "git rm" to resolve a conflicted path leaked an internal message
+   "needs merge" before actually removing the path, which was
+   confusing.  This has been corrected.
+
+ * The "git clone" documentation refers to command line options in its
+   description in the short form; they have been replaced with long
+   forms to make them more recognisable.
+
+ * The configuration variable rebase.rescheduleFailedExec should be
+   effective only while running an interactive rebase and should not
+   affect anything when running a non-interactive one, which was not
+   the case.  This has been corrected.
+
+ * "git submodule foreach" did not protect command line options passed
+   to the command to be run in each submodule correctly, when the
+   "--recursive" option was in use.
+
+ * Use "Erase in Line" CSI sequence that is already used in the editor
+   support to clear cruft in the progress output.
+
+ * The codepath to compute delta islands used to spew progress output
+   without giving the callers any way to squelch it, which has been
+   fixed.
+
+ * The code to parse scaled numbers out of configuration files has
+   been made more robust and also easier to follow.
+
+ * An incorrect list of options was cached after command line
+   completion failed (e.g. trying to complete a command that requires
+   a repository outside one), which has been corrected.
+
+ * "git rebase --abort" used to leave refs/rewritten/ when concluding
+   "git rebase -r", which has been corrected.
+
+ * "git stash show 23" used to work, but no more after getting
+   rewritten in C; this regression has been corrected.
+
+ * "git interpret-trailers" always treated '#' as the comment
+   character, regardless of core.commentChar setting, which has been
+   corrected.
+
+ * Code clean-up to avoid signed integer overlaps during binary search.
+
+ * "git checkout -p" needs to selectively apply a patch in reverse,
+   which did not work well.
+
+ * The commit-graph file is now part of the "files that the runtime
+   may keep open file descriptors on, all of which would need to be
+   closed when done with the object store", and the file descriptor to
+   an existing commit-graph file now is closed before "gc" finalizes a
+   new instance to replace it.
+
+ * Code restructuring during 2.20 period broke fetching tags via
+   "import" based transports.
+
+ * We have been trying out a few language features outside c89; the
+   coding guidelines document did not talk about them and instead had
+   a blanket ban against them.
+
+ * The internal diff machinery can be made to read out of bounds while
+   looking for --funcion-context line in a corner case, which has been
+   corrected.
+
+Also contains various documentation updates, code clean-ups and minor fixups.
index a6cd592..e3c4e78 100644 (file)
@@ -10,6 +10,9 @@ Backward compatibility note
    prerequisite patches in an unstable way, which has been updated to
    compute in a way that is compatible with "git patch-id --stable".
 
+ * The "git log" command by default behaves as if the --mailmap option
+   was given.
+
 
 UI, Workflows & Features
 
@@ -46,6 +49,54 @@ UI, Workflows & Features
  * The pattern "git diff/grep" use to extract funcname and words
    boundary for Rust has been added.
 
+ * "git status" can be told a non-standard default value for the
+   "--[no-]ahead-behind" option with a new configuration variable
+   status.aheadBehind.
+
+ * "git fetch" and "git pull" reports when a fetch results in
+   non-fast-forward updates to let the user notice unusual situation.
+   The commands learned "--no-show-forced-updates" option to disable
+   this safety feature.
+
+ * Two new commands "git switch" and "git restore" are introduced to
+   split "checking out a branch to work on advancing its history" and
+   "checking out paths out of the index and/or a tree-ish to work on
+   advancing the current history" out of the single "git checkout"
+   command.
+
+ * "git branch --list" learned to always output the detached HEAD as
+   the first item (when the HEAD is detached, of course), regardless
+   of the locale.
+
+ * The conditional inclusion mechanism learned to base the choice on
+   the branch the HEAD currently is on.
+
+ * "git rev-list --objects" learned the "--no-object-names" option to
+   squelch the path to the object that is used as a grouping hint for
+   pack-objects.
+
+ * A new tag.gpgSign configuration variable turns "git tag -a" into
+   "git tag -s".
+
+ * "git multi-pack-index" learned expire and repack subcommands.
+
+ * "git blame" learned to "ignore" commits in the history, whose
+   effects (as well as their presence) get ignored.
+
+ * "git cherry-pick/revert" learned a new "--skip" action.
+
+ * The tips of refs from the alternate object store can be used as
+   starting point for reachability computation now.
+
+ * Extra blank lines in "git status" output have been reduced.
+
+ * The commits in a repository can be described by multiple
+   commit-graph files now, which allows the commit-graph files to be
+   updated incrementally.
+
+ * "git range-diff" output has been tweaked for easier identification
+   of which part of what file the patch shown is about.
+
 
 Performance, Internal Implementation, Development Support etc.
 
@@ -53,7 +104,7 @@ Performance, Internal Implementation, Development Support etc.
    no longer be used.
 
  * Developer support to emulate unsatisfied prerequisites in tests to
-   ensure that the remainer of the tests still succeeds when tests
+   ensure that the remainder of the tests still succeeds when tests
    with prerequisites are skipped.
 
  * "git update-server-info" learned not to rewrite the file with the
@@ -68,9 +119,52 @@ Performance, Internal Implementation, Development Support etc.
  * Prepare use of reachability index in topological walker that works
    on a range (A..B).
 
- * A new tutorial targetting specifically aspiring git-core
+ * A new tutorial targeting specifically aspiring git-core
    developers has been added.
 
+ * Auto-detect how to tell HP-UX aCC where to use dynamically linked
+   libraries from at runtime.
+
+ * "git mergetool" and its tests now spawn fewer subprocesses.
+
+ * Dev support update to help tracing out tests.
+
+ * Support to build with MSVC has been updated.
+
+ * "git fetch" that grabs from a group of remotes learned to run the
+   auto-gc only once at the very end.
+
+ * A handful of Windows build patches have been upstreamed.
+
+ * The code to read state files used by the sequencer machinery for
+   "git status" has been made more robust against a corrupt or stale
+   state files.
+
+ * "git for-each-ref" with multiple patterns have been optimized.
+
+ * The tree-walk API learned to pass an in-core repository
+   instance throughout more codepaths.
+
+ * When one step in multi step cherry-pick or revert is reset or
+   committed, the command line prompt script failed to notice the
+   current status, which has been improved.
+
+ * Many GIT_TEST_* environment variables control various aspects of
+   how our tests are run, but a few followed "non-empty is true, empty
+   or unset is false" while others followed the usual "there are a few
+   ways to spell true, like yes, on, etc., and also ways to spell
+   false, like no, off, etc." convention.
+
+ * Adjust the dir-iterator API and apply it to the local clone
+   optimization codepath.
+
+ * We have been trying out a few language features outside c89; the
+   coding guidelines document did not talk about them and instead had
+   a blanket ban against them.
+
+ * A test helper has been introduced to optimize preparation of test
+   repositories with many simple commits, and a handful of test
+   scripts have been updated to use it.
 
 
 Fixes since v2.22
@@ -80,16 +174,13 @@ Fixes since v2.22
    ought to be relative to the directory "git init" gets invoked in,
    but it instead was made relative to the repository, which has been
    corrected.
-   (merge e1df7fe43f nd/init-relative-template-fix later to maint).
 
  * "git worktree add" used to fail when another worktree connected to
    the same repository was corrupt, which has been corrected.
-   (merge 105df73e71 nd/corrupt-worktrees later to maint).
 
  * The ownership rule for the file descriptor to fast-import remote
-   backend was mixed up, leading to unrelated file descriptor getting
+   backend was mixed up, leading to an unrelated file descriptor getting
    closed, which has been fixed.
-   (merge 3203566a71 mh/import-transport-fd-fix later to maint).
 
  * A "merge -c" instruction during "git rebase --rebase-merges" should
    give the user a chance to edit the log message, even when there is
@@ -98,86 +189,160 @@ Fixes since v2.22
    corrected.
 
  * Code cleanup and futureproof.
-   (merge 31f5256c82 ds/object-info-for-prefetch-fix later to maint).
 
  * More parameter validation.
-   (merge de99eb0c24 es/grep-require-name-when-needed later to maint).
 
  * "git update-server-info" used to leave stale packfiles in its
    output, which has been corrected.
-   (merge e941c48d49 ew/server-info-remove-crufts later to maint).
 
  * The server side support for "git fetch" used to show incorrect
    value for the HEAD symbolic ref when the namespace feature is in
    use, which has been corrected.
-   (merge 533e088250 jk/HEAD-symref-in-xfer-namespaces later to maint).
 
  * "git am -i --resolved" segfaulted after trying to see a commit as
    if it were a tree, which has been corrected.
-   (merge 7663e438c5 jk/am-i-resolved-fix later to maint).
 
  * "git bundle verify" needs to see if prerequisite objects exist in
    the receiving repository, but the command did not check if we are
    in a repository upfront, which has been corrected.
-   (merge 3bbbe467f2 js/bundle-verify-require-object-store later to maint).
 
  * "git merge --squash" is designed to update the working tree and the
    index without creating the commit, and this cannot be countermanded
    by adding the "--commit" option; the command now refuses to work
    when both options are given.
-   (merge 1d14d0c994 vv/merge-squash-with-explicit-commit later to maint).
 
  * The data collected by fsmonitor was not properly written back to
    the on-disk index file, breaking t7519 tests occasionally, which
    has been corrected.
-   (merge b5a8169752 js/fsmonitor-unflake later to maint).
 
  * Update to Unicode 12.1 width table.
-   (merge 5817f9caa3 bb/unicode-12.1-reiwa later to maint).
 
  * The command line to invoke a "git cat-file" command from inside
    "git p4" was not properly quoted to protect a caret and running a
    broken command on Windows, which has been corrected.
-   (merge c3f2358de3 mm/p4-unshelve-windows-fix later to maint).
 
  * "git request-pull" learned to warn when the ref we ask them to pull
    from in the local repository and in the published repository are
    different.
-   (merge 0454220d66 pb/request-pull-verify-remote-ref later to maint).
 
  * When creating a partial clone, the object filtering criteria is
    recorded for the origin of the clone, but this incorrectly used a
    hardcoded name "origin" to name that remote; it has been corrected
    to honor the "--origin <name>" option.
-   (merge 1c4a9f9114 xl/record-partial-clone-origin later to maint).
 
  * "git fetch" into a lazy clone forgot to fetch base objects that are
    necessary to complete delta in a thin packfile, which has been
    corrected.
-   (merge 810e19322d jt/partial-clone-missing-ref-delta-base later to maint).
 
  * The filter_data used in the list-objects-filter (which manages a
    lazily sparse clone repository) did not use the dynamic array API
    correctly---'nr' is supposed to point at one past the last element
    of the array in use.  This has been corrected.
-   (merge 7140600e2e md/list-objects-filter-memfix later to maint).
 
  * The description about slashes in gitignore patterns (used to
    indicate things like "anchored to this level only" and "only
    matches directories") has been revamped.
-   (merge 1a58bad014 an/ignore-doc-update later to maint).
 
  * The URL decoding code has been updated to avoid going past the end
    of the string while parsing %-<hex>-<hex> sequence.
-   (merge d37dc239a4 md/url-parse-harden later to maint).
 
  * The list of for-each like macros used by clang-format has been
    updated.
-   (merge fc7e03aace mo/clang-format-for-each-update later to maint).
+
+ * "git branch --list" learned to show branches that are checked out
+   in other worktrees connected to the same repository prefixed with
+   '+', similar to the way the currently checked out branch is shown
+   with '*' in front.
+   (merge 6e9381469e nb/branch-show-other-worktrees-head later to maint).
+
+ * Code restructuring during 2.20 period broke fetching tags via
+   "import" based transports.
+
+ * The commit-graph file is now part of the "files that the runtime
+   may keep open file descriptors on, all of which would need to be
+   closed when done with the object store", and the file descriptor to
+   an existing commit-graph file now is closed before "gc" finalizes a
+   new instance to replace it.
+
+ * "git checkout -p" needs to selectively apply a patch in reverse,
+   which did not work well.
+
+ * Code clean-up to avoid signed integer wraparounds during binary search.
+
+ * "git interpret-trailers" always treated '#' as the comment
+   character, regardless of core.commentChar setting, which has been
+   corrected.
+
+ * "git stash show 23" used to work, but no more after getting
+   rewritten in C; this regression has been corrected.
+
+ * "git rebase --abort" used to leave refs/rewritten/ when concluding
+   "git rebase -r", which has been corrected.
+
+ * An incorrect list of options was cached after command line
+   completion failed (e.g. trying to complete a command that requires
+   a repository outside one), which has been corrected.
+
+ * The code to parse scaled numbers out of configuration files has
+   been made more robust and also easier to follow.
+
+ * The codepath to compute delta islands used to spew progress output
+   without giving the callers any way to squelch it, which has been
+   fixed.
+
+ * Protocol capabilities that go over wire should never be translated,
+   but it was incorrectly marked for translation, which has been
+   corrected.  The output of protocol capabilities for debugging has
+   been tweaked a bit.
+
+ * Use "Erase in Line" CSI sequence that is already used in the editor
+   support to clear cruft in the progress output.
+
+ * "git submodule foreach" did not protect command line options passed
+   to the command to be run in each submodule correctly, when the
+   "--recursive" option was in use.
+
+ * The configuration variable rebase.rescheduleFailedExec should be
+   effective only while running an interactive rebase and should not
+   affect anything when running a non-interactive one, which was not
+   the case.  This has been corrected.
+
+ * The "git clone" documentation refers to command line options in its
+   description in the short form; they have been replaced with long
+   forms to make them more recognisable.
+
+ * Generation of pack bitmaps are now disabled when .keep files exist,
+   as these are mutually exclusive features.
+   (merge 7328482253 ew/repack-with-bitmaps-by-default later to maint).
+
+ * "git rm" to resolve a conflicted path leaked an internal message
+   "needs merge" before actually removing the path, which was
+   confusing.  This has been corrected.
+
+ * "git stash --keep-index" did not work correctly on paths that have
+   been removed, which has been fixed.
+   (merge b932f6a5e8 tg/stash-keep-index-with-removed-paths later to maint).
+
+ * Window 7 update ;-)
+
+ * A codepath that reads from GPG for signed object verification read
+   past the end of allocated buffer, which has been fixed.
+
+ * "git clean" silently skipped a path when it cannot lstat() it; now
+   it gives a warning.
+
+ * "git push --atomic" that goes over the transport-helper (namely,
+   the smart http transport) failed to prevent refs to be pushed when
+   it can locally tell that one of the ref update will fail without
+   having to consult the other end, which has been corrected.
+
+ * The internal diff machinery can be made to read out of bounds while
+   looking for --function-context line in a corner case, which has been
+   corrected.
+   (merge b777f3fd61 jk/xdiff-clamp-funcname-context-index later to maint).
 
  * Other code cleanup, docfix, build fix, etc.
-   (merge f547101b26 es/git-debugger-doc later to maint).
-   (merge 7877ac3d7b js/bisect-helper-check-get-oid-return-value later to maint).
-   (merge 0108f47eb3 sw/git-p4-unshelve-branched-files later to maint).
-   (merge 9df8f734fd cm/send-email-document-req-modules later to maint).
-   (merge afc3bf6eb1 ab/hash-object-doc later to maint).
+   (merge fbec05c210 cc/test-oidmap later to maint).
+   (merge 7a06fb038c jk/no-system-includes-in-dot-c later to maint).
+   (merge 81ed2b405c cb/xdiff-no-system-includes-in-dot-c later to maint).
+   (merge d61e6ce1dd sg/fsck-config-in-doc later to maint).
diff --git a/Documentation/RelNotes/2.24.0.txt b/Documentation/RelNotes/2.24.0.txt
new file mode 100644 (file)
index 0000000..ff48d85
--- /dev/null
@@ -0,0 +1,143 @@
+Git 2.24 Release Notes
+======================
+
+Updates since v2.23
+-------------------
+
+Backward compatibility note
+
+ * (no entry yet so far)
+
+
+UI, Workflows & Features
+
+ * We now have an active interim maintainer for the Git-Gui part of
+   the system.  Praise and thank Pratyush Yadav for volunteering.
+
+ * The command line parser learned "--end-of-options" notation; the
+   standard convention for scripters to have hardcoded set of options
+   first on the command line, and force the command to treat end-user
+   input as non-options, has been to use "--" as the delimiter, but
+   that would not work for commands that use "--" as a delimiter
+   between revs and pathspec.
+
+ * A mechanism to affect the default setting for a (related) group of
+   configuration variables is introduced.
+
+ * "git fetch" learned "--set-upstream" option to help those who first
+   clone from their private fork they intend to push to, add the true
+   upstream via "git remote add" and then "git fetch" from it.
+
+ * Device-tree files learned their own userdiff patterns.
+   (merge 3c81760bc6 sb/userdiff-dts later to maint).
+
+ * "git rebase --rebase-merges" learned to drive different merge
+   strategies and pass strategy specific options to them.
+
+ * A new "pre-merge-commit" hook has been introduced.
+
+ * Command line completion updates for "git -c var.name=val" have been
+   added.
+
+ * The lazy clone machinery has been taught that there can be more
+   than one promisor remote and consult them in order when downloading
+   missing objects on demand.
+
+ * The list-objects-filter API (used to create a sparse/lazy clone)
+   learned to take a combined filter specification.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The code to write commit-graph over given commit object names has
+   been made a bit more robust.
+
+ * The first line of verbose output from each test piece now carries
+   the test name and number to help scanning with eyeballs.
+
+ * Further clean-up of the initialization code.
+
+ * xmalloc() used to have a mechanism to ditch memory and address
+   space resources as the last resort upon seeing an allocation
+   failure from the underlying malloc(), which made the code complex
+   and thread-unsafe with dubious benefit, as major memory resource
+   users already do limit their uses with various other mechanisms.
+   It has been simplified away.
+
+ * Unnecessary full-tree diff in "git log -L" machinery has been
+   optimized away.
+
+ * The http transport lacked some optimization the native transports
+   learned to avoid unnecessary ref advertisement, which has been
+   corrected.
+
+
+Fixes since v2.23
+-----------------
+
+ * "git grep --recurse-submodules" that looks at the working tree
+   files looked at the contents in the index in submodules, instead of
+   files in the working tree.
+   (merge 6a289d45c0 mt/grep-submodules-working-tree later to maint).
+
+ * Codepaths to walk tree objects have been audited for integer
+   overflows and hardened.
+   (merge 5aa02f9868 jk/tree-walk-overflow later to maint).
+
+ * "git pack-refs" can lose refs that are created while running, which
+   is getting corrected.
+   (merge a613d4f817 sc/pack-refs-deletion-racefix later to maint).
+
+ * "git checkout" and "git restore" to re-populate the index from a
+   tree-ish (typically HEAD) did not work correctly for a path that
+   was removed and then added again with the intent-to-add bit, when
+   the corresponding working tree file was empty.  This has been
+   corrected.
+
+ * Compilation fix.
+   (merge 70597e8386 rs/nedalloc-fixlets later to maint).
+
+ * "git gui" learned to call the clean-up procedure before exiting.
+   (merge 0d88f3d2c5 py/git-gui-do-quit later to maint).
+
+ * We promoted the "indent heuristics" that decides where to split
+   diff hunks from experimental to the default a few years ago, but
+   some stale documentation still marked it as experimental, which has
+   been corrected.
+   (merge 64e5e1fba1 sg/diff-indent-heuristic-non-experimental later to maint).
+
+ * Fix a mismerge that happened in 2.22 timeframe.
+   (merge acb7da05ac en/checkout-mismerge-fix later to maint).
+
+ * "git archive" recorded incorrect length in extended pax header in
+   some corner cases, which has been corrected.
+   (merge 71d41ff651 rs/pax-extended-header-length-fix later to maint).
+
+ * On-demand object fetching in lazy clone incorrectly tried to fetch
+   commits from submodule projects, while still working in the
+   superproject, which has been corrected.
+   (merge a63694f523 jt/diff-lazy-fetch-submodule-fix later to maint).
+
+ * Prepare get_short_oid() codepath to be thread-safe.
+   (merge 7cfcb16b0e rs/sort-oid-array-thread-safe later to maint).
+
+ * "for-each-ref" and friends that show refs did not protect themselves
+   against ancient tags that did not record tagger names when asked to
+   show "%(taggername)", which have been corrected.
+   (merge 8b3f33ef11 mp/for-each-ref-missing-name-or-email later to maint).
+
+ * The "git am" based backend of "git rebase" ignored the result of
+   updating ".gitattributes" done in one step when replaying
+   subsequent steps.
+   (merge 2c65d90f75 bc/reread-attributes-during-rebase later to maint).
+
+ * Tell cURL library to use the same malloc() implementation, with the
+   xmalloc() wrapper, as the rest of the system, for consistency.
+   (merge 93b980e58f cb/curl-use-xmalloc later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+   (merge d1387d3895 en/fast-import-merge-doc later to maint).
+   (merge 1c24a54ea4 bm/repository-layout-typofix later to maint).
+   (merge 415b770b88 ds/midx-expire-repack later to maint).
+   (merge 19800bdc3f nd/diff-parseopt later to maint).
+   (merge 58166c2e9d tg/t0021-racefix later to maint).
index dc41957..5d122db 100644 (file)
@@ -110,5 +110,24 @@ commit. And the default value is 40. If there are more than one
 `-C` options given, the <num> argument of the last `-C` will
 take effect.
 
+--ignore-rev <rev>::
+       Ignore changes made by the revision when assigning blame, as if the
+       change never happened.  Lines that were changed or added by an ignored
+       commit will be blamed on the previous commit that changed that line or
+       nearby lines.  This option may be specified multiple times to ignore
+       more than one revision.  If the `blame.markIgnoredLines` config option
+       is set, then lines that were changed by an ignored commit and attributed to
+       another commit will be marked with a `?` in the blame output.  If the
+       `blame.markUnblamableLines` config option is set, then those lines touched
+       by an ignored commit that we could not attribute to another revision are
+       marked with a '*'.
+
+--ignore-revs-file <file>::
+       Ignore revisions listed in `file`, which must be in the same format as an
+       `fsck.skipList`.  This option may be repeated, and these files will be
+       processed after any files specified with the `blame.ignoreRevsFile` config
+       option.  An empty file name, `""`, will clear the list of revs from
+       previously processed files.
+
 -h::
        Show help message.
index 7e2a6f6..77f3b14 100644 (file)
@@ -144,6 +144,20 @@ refer to linkgit:gitignore[5] for details. For convenience:
        This is the same as `gitdir` except that matching is done
        case-insensitively (e.g. on case-insensitive file sytems)
 
+`onbranch`::
+       The data that follows the keyword `onbranch:` is taken to be a
+       pattern with standard globbing wildcards and two additional
+       ones, `**/` and `/**`, that can match multiple path components.
+       If we are in a worktree where the name of the branch that is
+       currently checked out matches the pattern, the include condition
+       is met.
++
+If the pattern ends with `/`, `**` will be automatically added. For
+example, the pattern `foo/` becomes `foo/**`. In other words, it matches
+all branches that begin with `foo/`. This is useful if your branches are
+organized hierarchically and you would like to apply a configuration to
+all the branches in that hierarchy.
+
 A few more notes on matching via `gitdir` and `gitdir/i`:
 
  * Symlinks in `$GIT_DIR` are not resolved before matching.
@@ -206,6 +220,11 @@ Example
        [includeIf "gitdir:/path/to/group/"]
                path = foo.inc
 
+       ; include only if we are in a worktree where foo-branch is
+       ; currently checked out
+       [includeIf "onbranch:foo-branch"]
+               path = foo.inc
+
 Values
 ~~~~~~
 
@@ -326,6 +345,8 @@ include::config/difftool.txt[]
 
 include::config/fastimport.txt[]
 
+include::config/feature.txt[]
+
 include::config/fetch.txt[]
 
 include::config/format.txt[]
index ec4f6ae..6aaa360 100644 (file)
@@ -4,6 +4,10 @@ advice.*::
        can tell Git that you do not need help by setting these to 'false':
 +
 --
+       fetchShowForcedUpdates::
+               Advice shown when linkgit:git-fetch[1] takes a long time
+               to calculate forced updates after ref updates, or to warn
+               that the check is disabled.
        pushUpdateRejected::
                Set this variable to 'false' if you want to disable
                'pushNonFFCurrent',
@@ -37,12 +41,19 @@ advice.*::
                we can still suggest that the user push to either
                refs/heads/* or refs/tags/* based on the type of the
                source object.
+       statusAheadBehind::
+               Shown when linkgit:git-status[1] computes the ahead/behind
+               counts for a local ref compared to its remote tracking ref,
+               and that calculation takes longer than expected. Will not
+               appear if `status.aheadBehind` is false or the option
+               `--no-ahead-behind` is given.
        statusHints::
                Show directions on how to proceed from the current
                state in the output of linkgit:git-status[1], in
                the template shown when writing commit messages in
                linkgit:git-commit[1], and in the help message shown
-               by linkgit:git-checkout[1] when switching branch.
+               by linkgit:git-switch[1] or
+               linkgit:git-checkout[1] when switching branch.
        statusUoption::
                Advise to consider using the `-u` option to linkgit:git-status[1]
                when the command takes more than 2 seconds to enumerate untracked
@@ -57,17 +68,21 @@ advice.*::
        resolveConflict::
                Advice shown by various commands when conflicts
                prevent the operation from being performed.
+       sequencerInUse::
+               Advice shown when a sequencer command is already in progress.
        implicitIdentity::
                Advice on how to set your identity configuration when
                your information is guessed from the system username and
                domain name.
        detachedHead::
-               Advice shown when you used linkgit:git-checkout[1] to
-               move to the detach HEAD state, to instruct how to create
-               a local branch after the fact.
+               Advice shown when you used
+               linkgit:git-switch[1] or linkgit:git-checkout[1]
+               to move to the detach HEAD state, to instruct how to
+               create a local branch after the fact.
        checkoutAmbiguousRemoteBranchName::
                Advice shown when the argument to
-               linkgit:git-checkout[1] ambiguously resolves to a
+               linkgit:git-checkout[1] and linkgit:git-switch[1]
+               ambiguously resolves to a
                remote tracking branch on more than one remote in
                situations where an unambiguous argument would have
                otherwise caused a remote-tracking branch to be
index 0b14178..f1ca739 100644 (file)
@@ -1,18 +1,28 @@
 alias.*::
        Command aliases for the linkgit:git[1] command wrapper - e.g.
-       after defining "alias.last = cat-file commit HEAD", the invocation
-       "git last" is equivalent to "git cat-file commit HEAD". To avoid
+       after defining `alias.last = cat-file commit HEAD`, the invocation
+       `git last` is equivalent to `git cat-file commit HEAD`. To avoid
        confusion and troubles with script usage, aliases that
        hide existing Git commands are ignored. Arguments are split by
        spaces, the usual shell quoting and escaping is supported.
        A quote pair or a backslash can be used to quote them.
 +
+Note that the first word of an alias does not necessarily have to be a
+command. It can be a command-line option that will be passed into the
+invocation of `git`. In particular, this is useful when used with `-c`
+to pass in one-time configurations or `-p` to force pagination. For example,
+`loud-rebase = -c commit.verbose=true rebase` can be defined such that
+running `git loud-rebase` would be equivalent to
+`git -c commit.verbose=true rebase`. Also, `ps = -p status` would be a
+helpful alias since `git ps` would paginate the output of `git status`
+where the original command does not.
++
 If the alias expansion is prefixed with an exclamation point,
 it will be treated as a shell command.  For example, defining
-"alias.new = !gitk --all --not ORIG_HEAD", the invocation
-"git new" is equivalent to running the shell command
-"gitk --all --not ORIG_HEAD".  Note that shell commands will be
+`alias.new = !gitk --all --not ORIG_HEAD`, the invocation
+`git new` is equivalent to running the shell command
+`gitk --all --not ORIG_HEAD`.  Note that shell commands will be
 executed from the top-level directory of a repository, which may
 not necessarily be the current directory.
-`GIT_PREFIX` is set as returned by running 'git rev-parse --show-prefix'
+`GIT_PREFIX` is set as returned by running `git rev-parse --show-prefix`
 from the original current directory. See linkgit:git-rev-parse[1].
index 67b5c1d..9468e85 100644 (file)
@@ -19,3 +19,19 @@ blame.showEmail::
 blame.showRoot::
        Do not treat root commits as boundaries in linkgit:git-blame[1].
        This option defaults to false.
+
+blame.ignoreRevsFile::
+       Ignore revisions listed in the file, one unabbreviated object name per
+       line, in linkgit:git-blame[1].  Whitespace and comments beginning with
+       `#` are ignored.  This option may be repeated multiple times.  Empty
+       file names will reset the list of ignored revisions.  This option will
+       be handled before the command line option `--ignore-revs-file`.
+
+blame.markUnblamables::
+       Mark lines that were changed by an ignored revision that we could not
+       attribute to another commit with a '*' in the output of
+       linkgit:git-blame[1].
+
+blame.markIgnoredLines::
+       Mark lines that were changed by an ignored revision that we attributed to
+       another commit with a '?' in the output of linkgit:git-blame[1].
index 8f4b3fa..a592d52 100644 (file)
@@ -1,5 +1,5 @@
 branch.autoSetupMerge::
-       Tells 'git branch' and 'git checkout' to set up new branches
+       Tells 'git branch', 'git switch' and 'git checkout' to set up new branches
        so that linkgit:git-pull[1] will appropriately merge from the
        starting point branch. Note that even if this option is not set,
        this behavior can be chosen per-branch using the `--track`
@@ -11,7 +11,7 @@ branch.autoSetupMerge::
        branch. This option defaults to true.
 
 branch.autoSetupRebase::
-       When a new branch is created with 'git branch' or 'git checkout'
+       When a new branch is created with 'git branch', 'git switch' or 'git checkout'
        that tracks another branch, this variable tells Git to set
        up pull to rebase instead of merge (see "branch.<name>.rebase").
        When `never`, rebase is never automatically set to true.
index c4118fa..6b64681 100644 (file)
@@ -1,5 +1,6 @@
 checkout.defaultRemote::
-       When you run 'git checkout <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>'
@@ -8,16 +9,10 @@ checkout.defaultRemote::
        disambiguation. The typical use-case is to set this to
        `origin`.
 +
-Currently this is used by linkgit:git-checkout[1] when 'git checkout
-<something>' will checkout the '<something>' branch on another remote,
+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
 remote branch. This setting might be used for other checkout-like
 commands or functionality in the future.
-
-checkout.optimizeNewBranch::
-       Optimizes the performance of "git checkout -b <new_branch>" when
-       using sparse-checkout.  When set to true, git will not update the
-       repo based on the current sparse-checkout settings.  This means it
-       will not update the skip-worktree bit in the index nor add/remove
-       files in the working directory to reflect the current sparse checkout
-       settings nor will it show the local changes.
index 8375596..d5daacb 100644 (file)
@@ -14,7 +14,7 @@ color.blame.highlightRecent::
 +
 This setting should be set to a comma-separated list of color and date settings,
 starting and ending with a color, the dates should be set from oldest to newest.
-The metadata will be colored given the colors if the the line was introduced
+The metadata will be colored given the colors if the line was introduced
 before the given timestamp, overwriting older timestamped colors.
 +
 Instead of an absolute timestamp relative timestamps work as well, e.g.
index 75538d2..852d2ba 100644 (file)
@@ -86,7 +86,9 @@ core.untrackedCache::
        it will automatically be removed, if set to `false`. Before
        setting it to `true`, you should check that mtime is working
        properly on your system.
-       See linkgit:git-update-index[1]. `keep` by default.
+       See linkgit:git-update-index[1]. `keep` by default, unless
+       `feature.manyFiles` is enabled which sets this setting to
+       `true` by default.
 
 core.checkStat::
        When missing or is set to `default`, many fields in the stat
@@ -577,7 +579,7 @@ the `GIT_NOTES_REF` environment variable.  See linkgit:git-notes[1].
 
 core.commitGraph::
        If true, then git will read the commit-graph file (if it exists)
-       to parse the graph structure of commits. Defaults to false. See
+       to parse the graph structure of commits. Defaults to true. See
        linkgit:git-commit-graph[1] for more information.
 
 core.useReplaceRefs::
index 2c4c9ba..ff09f1c 100644 (file)
@@ -78,7 +78,8 @@ diff.external::
 diff.ignoreSubmodules::
        Sets the default value of --ignore-submodules. Note that this
        affects only 'git diff' Porcelain, and not lower level 'diff'
-       commands such as 'git diff-files'. 'git checkout' also honors
+       commands such as 'git diff-files'. 'git checkout'
+       and 'git switch' also honor
        this setting when reporting uncommitted changes. Setting it to
        'all' disables the submodule summary normally shown by 'git commit'
        and 'git status' when `status.submoduleSummary` is set unless it is
@@ -188,7 +189,7 @@ diff.guitool::
 include::../mergetools-diff.txt[]
 
 diff.indentHeuristic::
-       Set this option to `true` to enable experimental heuristics
+       Set this option to `false` to disable the default heuristics
        that shift diff hunk boundaries to make patches easier to read.
 
 diff.algorithm::
diff --git a/Documentation/config/feature.txt b/Documentation/config/feature.txt
new file mode 100644 (file)
index 0000000..545522f
--- /dev/null
@@ -0,0 +1,29 @@
+feature.*::
+       The config settings that start with `feature.` modify the defaults of
+       a group of other config settings. These groups are created by the Git
+       developer community as recommended defaults and are subject to change.
+       In particular, new config options may be added with different defaults.
+
+feature.experimental::
+       Enable config options that are new to Git, and are being considered for
+       future defaults. Config settings included here may be added or removed
+       with each release, including minor version updates. These settings may
+       have unintended interactions since they are so new. Please enable this
+       setting if you are interested in providing feedback on experimental
+       features. The new default values are:
++
+* `pack.useSparse=true` uses a new algorithm when constructing a pack-file
+which can improve `git push` performance in repos with many files.
++
+* `fetch.negotiationAlgorithm=skipping` may improve fetch negotiation times by
+skipping more commits at a time, reducing the number of round trips.
+
+feature.manyFiles::
+       Enable config options that optimize for repos with many files in the
+       working directory. With many files, commands such as `git status` and
+       `git checkout` may be slow and these new defaults improve performance:
++
+* `index.version=4` enables path-prefix compression in the index.
++
+* `core.untrackedCache=true` enables the untracked cache. This setting assumes
+that mtime is working on your machine.
index cbfad6c..d402110 100644 (file)
@@ -59,7 +59,13 @@ fetch.negotiationAlgorithm::
        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
        that never skips commits (unless the server has acknowledged it or one
-       of its descendants).
+       of its descendants). If `feature.experimental` is enabled, then this
+       setting defaults to "skipping".
        Unknown values will cause 'git fetch' to error out.
 +
 See also the `--negotiation-tip` option for linkgit:git-fetch[1].
+
+fetch.showForcedUpdates::
+       Set to false to enable `--no-show-forced-updates` in
+       linkgit:git-fetch[1] and linkgit:git-pull[1] commands.
+       Defaults to true.
index 414a5a8..cb629fa 100644 (file)
@@ -77,6 +77,7 @@ format.coverLetter::
        A boolean that controls whether to generate a cover-letter when
        format-patch is invoked, but in addition can be set to "auto", to
        generate a cover-letter only when there's more than one patch.
+       Default is false.
 
 format.outputDirectory::
        Set a custom directory to store the resulting files instead of the
index 02b92b1..00ea0a6 100644 (file)
@@ -63,7 +63,7 @@ gc.writeCommitGraph::
        If true, then gc will rewrite the commit-graph file when
        linkgit:git-gc[1] is run. When using `git gc --auto`
        the commit-graph will be updated if housekeeping is
-       required. Default is false. See linkgit:git-commit-graph[1]
+       required. Default is true. See linkgit:git-commit-graph[1]
        for details.
 
 gc.logExpiry::
index f999f8e..cce2c89 100644 (file)
@@ -2,7 +2,7 @@ gpg.program::
        Use this custom program instead of "`gpg`" found on `$PATH` when
        making or verifying a PGP signature. The program must support the
        same command-line interface as GPG, namely, to verify a detached
-       signature, "`gpg --verify $file - <$signature`" is run, and the
+       signature, "`gpg --verify $signature - <$file`" is run, and the
        program is expected to signal a good signature by exiting with
        code 0, and to generate an ASCII-armored detached signature, the
        standard input of "`gpg -bsau $key`" is fed with the contents to be
index f181503..7cb50b3 100644 (file)
@@ -24,3 +24,4 @@ index.threads::
 index.version::
        Specify the version with which new index files should be
        initialized.  This does not affect existing repositories.
+       If `feature.manyFiles` is enabled, then the default is 4.
index ad846dd..a2d3c7e 100644 (file)
@@ -2,7 +2,8 @@ interactive.singleKey::
        In interactive commands, allow the user to provide one-letter
        input with a single key (i.e., without hitting enter).
        Currently this is used by the `--patch` mode of
-       linkgit:git-add[1], linkgit:git-checkout[1], linkgit:git-commit[1],
+       linkgit:git-add[1], linkgit:git-checkout[1],
+       linkgit:git-restore[1], linkgit:git-commit[1],
        linkgit:git-reset[1], and linkgit:git-stash[1]. Note that this
        setting is silently ignored if portable keystroke input
        is not available; requires the Perl module Term::ReadKey.
index 78d9e44..e9e1e39 100644 (file)
@@ -40,4 +40,5 @@ log.showSignature::
 
 log.mailmap::
        If true, makes linkgit:git-log[1], linkgit:git-show[1], and
-       linkgit:git-whatchanged[1] assume `--use-mailmap`.
+       linkgit:git-whatchanged[1] assume `--use-mailmap`, otherwise
+       assume `--no-use-mailmap`. True by default.
index 9cdcfa7..1d66f0c 100644 (file)
@@ -112,7 +112,8 @@ pack.useSparse::
        objects. This can have significant performance benefits when
        computing a pack to send a small change. However, it is possible
        that extra objects are added to the pack-file if the included
-       commits contain certain types of direct renames.
+       commits contain certain types of direct renames. Default is `false`
+       unless `feature.experimental` is enabled.
 
 pack.writeBitmaps (deprecated)::
        This is a deprecated synonym for `repack.writeBitmaps`.
index 6c4cad8..a8e6437 100644 (file)
@@ -76,3 +76,11 @@ remote.<name>.pruneTags::
 +
 See also `remote.<name>.prune` and the PRUNING section of
 linkgit:git-fetch[1].
+
+remote.<name>.promisor::
+       When set to true, this remote will be used to fetch promisor
+       objects.
+
+remote.<name>.partialclonefilter::
+       The filter that will be applied when fetching from this
+       promisor remote.
index 7710758..abc7ef4 100644 (file)
@@ -4,7 +4,7 @@ stash.useBuiltin::
        the built-in rewrite of it in C.
 +
 The C rewrite is first included with Git version 2.22 (and Git for Windows
-version 2.19). This option serves an an escape hatch to re-enable the
+version 2.19). This option serves as an escape hatch to re-enable the
 legacy version in case any bugs are found in the rewrite. This option and
 the shell script version of linkgit:git-stash[1] will be removed in some
 future release.
index ed72fa7..0fc704a 100644 (file)
@@ -12,6 +12,11 @@ status.branch::
        Set to true to enable --branch by default in linkgit:git-status[1].
        The option --no-branch takes precedence over this variable.
 
+status.aheadBehind::
+       Set to true to enable `--ahead-behind` and false to enable
+       `--no-ahead-behind` by default in linkgit:git-status[1] for
+       non-porcelain status formats.  Defaults to true.
+
 status.displayCommentPrefix::
        If set to true, linkgit:git-status[1] will insert a comment
        prefix before each output line (starting with
index 663663b..ef5adb3 100644 (file)
@@ -8,6 +8,14 @@ tag.sort::
        linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the
        value of this variable will be used as the default.
 
+tag.gpgSign::
+       A boolean to specify whether all tags should be GPG signed.
+       Use of this option when running in an automated script can
+       result in a large number of tags being signed. It is therefore
+       convenient to use an agent to avoid typing your gpg passphrase
+       several times. Note that this option doesn't affects tag signing
+       behavior enabled by "-u <keyid>" or "--local-user=<keyid>" options.
+
 tar.umask::
        This variable can be used to restrict the permission bits of
        tar archive entries.  The default is 0002, which turns off the
index 4a5dfe2..f5b6245 100644 (file)
@@ -17,7 +17,7 @@ linkgit:git-receive-pack[1]. On the fetch side, malformed objects will
 instead be left unreferenced in the repository.
 +
 Due to the non-quarantine nature of the `fetch.fsckObjects`
-implementation it can not be relied upon to leave the object store
+implementation it cannot be relied upon to leave the object store
 clean like `receive.fsckObjects` can.
 +
 As objects are unpacked they're written to the object store, so there
index 91c4775..99df1f3 100644 (file)
@@ -88,6 +88,10 @@ ifndef::git-pull[]
        Allow several <repository> and <group> arguments to be
        specified. No <refspec>s may be specified.
 
+--[no-]auto-gc::
+       Run `git gc --auto` at the end to perform garbage collection
+       if needed. This is enabled by default.
+
 -p::
 --prune::
        Before fetching, remove any remote-tracking references that no
@@ -165,6 +169,13 @@ ifndef::git-pull[]
        Disable recursive fetching of submodules (this has the same effect as
        using the `--recurse-submodules=no` option).
 
+--set-upstream::
+       If the remote is fetched successfully, pull and 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
+       linkgit:git-config[1].
+
 --submodule-prefix=<path>::
        Prepend <path> to paths printed in informative messages
        such as "Fetching submodule foo".  This option is used
@@ -221,6 +232,19 @@ endif::git-pull[]
        When multiple `--server-option=<option>` are given, they are all
        sent to the other side in the order listed on the command line.
 
+--show-forced-updates::
+       By default, git checks if a branch is force-updated during
+       fetch. This can be disabled through fetch.showForcedUpdates, but
+       the --show-forced-updates option guarantees this check occurs.
+       See linkgit:git-config[1].
+
+--no-show-forced-updates::
+       By default, git checks if a branch is force-updated during
+       fetch. Pass --no-show-forced-updates or set fetch.showForcedUpdates
+       to false to skip this check for performance reasons. If used during
+       'git-pull' the --ff-only option will still check for forced updates
+       before attempting a fast-forward update. See linkgit:git-config[1].
+
 -4::
 --ipv4::
        Use IPv4 addresses only, ignoring IPv6 addresses.
index 16323eb..7e81541 100644 (file)
@@ -10,6 +10,7 @@ SYNOPSIS
 [verse]
 'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
            [-L <range>] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
+           [--ignore-rev <rev>] [--ignore-revs-file <file>]
            [--progress] [--abbrev=<n>] [<rev> | --contents <file> | --reverse <rev>..<rev>]
            [--] <file>
 
index 6ebd512..135206f 100644 (file)
@@ -8,12 +8,14 @@ git-branch - List, create, or delete branches
 SYNOPSIS
 --------
 [verse]
-'git branch' [--color[=<when>] | --no-color] [-r | -a]
-       [--list] [--show-current] [-v [--abbrev=<length> | --no-abbrev]]
+'git branch' [--color[=<when>] | --no-color] [--show-current]
+       [-v [--abbrev=<length> | --no-abbrev]]
        [--column[=<options>] | --no-column] [--sort=<key>]
        [(--merged | --no-merged) [<commit>]]
        [--contains [<commit]] [--no-contains [<commit>]]
-       [--points-at <object>] [--format=<format>] [<pattern>...]
+       [--points-at <object>] [--format=<format>]
+       [(-r | --remotes) | (-a | --all)]
+       [--list] [<pattern>...]
 'git branch' [--track | --no-track] [-f] <branchname> [<start-point>]
 'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
 'git branch' --unset-upstream [<branchname>]
@@ -26,13 +28,19 @@ DESCRIPTION
 -----------
 
 If `--list` is given, or if there are no non-option arguments, existing
-branches are listed; the current branch will be highlighted with an
-asterisk.  Option `-r` causes the remote-tracking branches to be listed,
-and option `-a` shows both local and remote branches. If a `<pattern>`
+branches are listed; the current branch will be highlighted in green and
+marked with an asterisk.  Any branches checked out in linked worktrees will
+be highlighted in cyan and marked with a plus sign. Option `-r` causes the
+remote-tracking branches to be listed,
+and option `-a` shows both local and remote branches.
+
+If a `<pattern>`
 is given, it is used as a shell wildcard to restrict the output to
 matching branches. If multiple patterns are given, a branch is shown if
-it matches any of the patterns.  Note that when providing a
-`<pattern>`, you must use `--list`; otherwise the command is interpreted
+it matches any of the patterns.
+
+Note that when providing a
+`<pattern>`, you must use `--list`; otherwise the command may be interpreted
 as branch creation.
 
 With `--contains`, shows only the branches that contain the named commit
@@ -52,7 +60,7 @@ can leave out at most one of `A` and `B`, in which case it defaults to
 `HEAD`.
 
 Note that this will create the new branch, but it will not switch the
-working tree to it; use "git checkout <newbranch>" to switch to the
+working tree to it; use "git switch <newbranch>" to switch to the
 new branch.
 
 When a local branch is started off a remote-tracking branch, Git sets up the
@@ -153,10 +161,12 @@ This option is only applicable in non-verbose mode.
 -r::
 --remotes::
        List or delete (if used with -d) the remote-tracking branches.
+       Combine with `--list` to match the optional pattern(s).
 
 -a::
 --all::
        List both remote-tracking branches and local branches.
+       Combine with `--list` to match optional pattern(s).
 
 -l::
 --list::
@@ -174,8 +184,10 @@ This option is only applicable in non-verbose mode.
        When in list mode,
        show sha1 and commit subject line for each head, along with
        relationship to upstream branch (if any). If given twice, print
-       the name of the upstream branch, as well (see also `git remote
-       show <remote>`).
+       the path of the linked worktree (if any) and the name of the upstream
+       branch, as well (see also `git remote show <remote>`).  Note that the
+       current worktree's HEAD will not have its path printed (it will always
+       be your current directory).
 
 -q::
 --quiet::
@@ -202,7 +214,7 @@ This option is only applicable in non-verbose mode.
 +
 This behavior is the default when the start point is a remote-tracking branch.
 Set the branch.autoSetupMerge configuration variable to `false` if you
-want `git checkout` and `git branch` to always behave as if `--no-track`
+want `git switch`, `git checkout` and `git branch` to always behave as if `--no-track`
 were given. Set it to `always` if you want this behavior when the
 start-point is either a local or remote-tracking branch.
 
@@ -301,7 +313,7 @@ Start development from a known tag::
 $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
 $ cd my2.6
 $ git branch my2.6.14 v2.6.14   <1>
-$ git checkout my2.6.14
+$ git switch my2.6.14
 ------------
 +
 <1> This step and the next one could be combined into a single step with
@@ -322,13 +334,25 @@ $ git branch -D test                                    <2>
 <2> Delete the "test" branch even if the "master" branch (or whichever branch
     is currently checked out) does not have all commits from the test branch.
 
+Listing branches from a specific remote::
++
+------------
+$ git branch -r -l '<remote>/<pattern>'                 <1>
+$ git for-each-ref 'refs/remotes/<remote>/<pattern>'    <2>
+------------
++
+<1> Using `-a` would conflate <remote> with any local branches you happen to
+    have been prefixed with the same <remote> pattern.
+<2> `for-each-ref` can take a wide range of options. See linkgit:git-for-each-ref[1]
+
+Patterns will normally need quoting.
 
 NOTES
 -----
 
-If you are creating a branch that you want to checkout immediately, it is
-easier to use the git checkout command with its `-b` option to create
-a branch and check it out with a single command.
+If you are creating a branch that you want to switch to immediately,
+it is easier to use the "git switch" command with its `-c` option to
+do the same thing with a single command.
 
 The options `--contains`, `--no-contains`, `--merged` and `--no-merged`
 serve four related but different purposes:
index d9de992..ee6a414 100644 (file)
@@ -88,7 +88,8 @@ but it is explicitly forbidden at the beginning of a branch name).
 When run with `--branch` option in a repository, the input is first
 expanded for the ``previous checkout syntax''
 `@{-n}`.  For example, `@{-1}` is a way to refer the last thing that
-was checked out using "git checkout" operation. This option should be
+was checked out using "git switch" or "git checkout" operation.
+This option should be
 used by porcelains to accept this syntax anywhere a branch name is
 expected, so they can act as if you typed the branch name. As an
 exception note that, the ``previous checkout operation'' might result
index 964f912..cf3cac0 100644 (file)
@@ -23,31 +23,22 @@ or the specified tree.  If no paths are given, 'git checkout' will
 also update `HEAD` to set the specified branch as the current
 branch.
 
-'git checkout' <branch>::
-       To prepare for working on <branch>, switch to it by updating
+'git checkout' [<branch>]::
+       To prepare for working on `<branch>`, switch to it by updating
        the index and the files in the working tree, and by pointing
-       HEAD at the branch. Local modifications to the files in the
+       `HEAD` at the branch. Local modifications to the files in the
        working tree are kept, so that they can be committed to the
-       <branch>.
+       `<branch>`.
 +
-If <branch> is not found but there does exist a tracking branch in
-exactly one remote (call it <remote>) with a matching name, treat as
-equivalent to
+If `<branch>` is not found but there does exist a tracking branch in
+exactly one remote (call it `<remote>`) with a matching name and
+`--no-guess` is not specified, treat as equivalent to
 +
 ------------
 $ git checkout -b <branch> --track <remote>/<branch>
 ------------
 +
-If the branch exists in multiple remotes and one of them is named by
-the `checkout.defaultRemote` configuration variable, we'll use that
-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
-linkgit:git-config[1].
-+
-You could omit <branch>, in which case the command degenerates to
+You could omit `<branch>`, in which case the command degenerates to
 "check out the current branch", which is a glorified no-op with
 rather expensive side-effects to show only the tracking information,
 if exists, for the current branch.
@@ -61,7 +52,7 @@ if exists, for the current branch.
        `--track` without `-b` implies branch creation; see the
        description of `--track` below.
 +
-If `-B` is given, <new_branch> is created if it doesn't exist; otherwise, it
+If `-B` is given, `<new_branch>` is created if it doesn't exist; otherwise, it
 is reset. This is the transactional equivalent of
 +
 ------------
@@ -75,25 +66,25 @@ successful.
 'git checkout' --detach [<branch>]::
 'git checkout' [--detach] <commit>::
 
-       Prepare to work on top of <commit>, by detaching HEAD at it
+       Prepare to work on top of `<commit>`, by detaching `HEAD` at it
        (see "DETACHED HEAD" section), and updating the index and the
        files in the working tree.  Local modifications to the files
        in the working tree are kept, so that the resulting working
        tree will be the state recorded in the commit plus the local
        modifications.
 +
-When the <commit> argument is a branch name, the `--detach` option can
-be used to detach HEAD at the tip of the branch (`git checkout
-<branch>` would check out that branch without detaching HEAD).
+When the `<commit>` argument is a branch name, the `--detach` option can
+be used to detach `HEAD` at the tip of the branch (`git checkout
+<branch>` would check out that branch without detaching `HEAD`).
 +
-Omitting <branch> detaches HEAD at the tip of the current branch.
+Omitting `<branch>` detaches `HEAD` at the tip of the current branch.
 
 'git checkout' [<tree-ish>] [--] <pathspec>...::
 
        Overwrite paths in the working tree by replacing with the
-       contents in the index or in the <tree-ish> (most often a
-       commit).  When a <tree-ish> is given, the paths that
-       match the <pathspec> are updated both in the index and in
+       contents in the index or in the `<tree-ish>` (most often a
+       commit).  When a `<tree-ish>` is given, the paths that
+       match the `<pathspec>` are updated both in the index and in
        the working tree.
 +
 The index may contain unmerged entries because of a previous failed merge.
@@ -118,7 +109,8 @@ OPTIONS
 --quiet::
        Quiet, suppress feedback messages.
 
---[no-]progress::
+--progress::
+--no-progress::
        Progress status is reported on the standard error stream
        by default when it is attached to a terminal, unless `--quiet`
        is specified. This flag enables progress reporting even if not
@@ -127,7 +119,7 @@ OPTIONS
 -f::
 --force::
        When switching branches, proceed even if the index or the
-       working tree differs from HEAD.  This is used to throw away
+       working tree differs from `HEAD`.  This is used to throw away
        local changes.
 +
 When checking out paths from the index, do not fail upon unmerged
@@ -154,12 +146,12 @@ on your side branch as `theirs` (i.e. "one contributor's work on top
 of it").
 
 -b <new_branch>::
-       Create a new branch named <new_branch> and start it at
-       <start_point>; see linkgit:git-branch[1] for details.
+       Create a new branch named `<new_branch>` and start it at
+       `<start_point>`; see linkgit:git-branch[1] for details.
 
 -B <new_branch>::
-       Creates the branch <new_branch> and start it at <start_point>;
-       if it already exists, then reset it to <start_point>. This is
+       Creates the branch `<new_branch>` and start it at `<start_point>`;
+       if it already exists, then reset it to `<start_point>`. This is
        equivalent to running "git branch" with "-f"; see
        linkgit:git-branch[1] for details.
 
@@ -172,15 +164,36 @@ If no `-b` option is given, the name of the new branch will be
 derived from the remote-tracking branch, by looking at the local part of
 the refspec configured for the corresponding remote, and then stripping
 the initial part up to the "*".
-This would tell us to use "hack" as the local branch when branching
-off of "origin/hack" (or "remotes/origin/hack", or even
-"refs/remotes/origin/hack").  If the given name has no slash, or the above
+This would tell us to use `hack` as the local branch when branching
+off of `origin/hack` (or `remotes/origin/hack`, or even
+`refs/remotes/origin/hack`).  If the given name has no slash, or the above
 guessing results in an empty name, the guessing is aborted.  You can
 explicitly give a name with `-b` in such a case.
 
 --no-track::
        Do not set up "upstream" configuration, even if the
-       branch.autoSetupMerge configuration variable is true.
+       `branch.autoSetupMerge` configuration variable is true.
+
+--guess::
+--no-guess::
+       If `<branch>` is not found but there does exist a tracking
+       branch in exactly one remote (call it `<remote>`) with a
+       matching name, treat as equivalent to
++
+------------
+$ git checkout -b <branch> --track <remote>/<branch>
+------------
++
+If the branch exists in multiple remotes and one of them is named by
+the `checkout.defaultRemote` configuration variable, we'll use that
+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
+linkgit:git-config[1].
++
+Use `--no-guess` to disable this.
 
 -l::
        Create the new branch's reflog; see linkgit:git-branch[1] for
@@ -189,21 +202,21 @@ explicitly give a name with `-b` in such a case.
 --detach::
        Rather than checking out a branch to work on it, check out a
        commit for inspection and discardable experiments.
-       This is the default behavior of "git checkout <commit>" when
-       <commit> is not a branch name.  See the "DETACHED HEAD" section
+       This is the default behavior of `git checkout <commit>` when
+       `<commit>` is not a branch name.  See the "DETACHED HEAD" section
        below for details.
 
 --orphan <new_branch>::
-       Create a new 'orphan' branch, named <new_branch>, started from
-       <start_point> and switch to it.  The first commit made on this
+       Create a new 'orphan' branch, named `<new_branch>`, started from
+       `<start_point>` and switch to it.  The first commit made on this
        new branch will have no parents and it will be the root of a new
        history totally disconnected from all the other branches and
        commits.
 +
 The index and the working tree are adjusted as if you had previously run
-"git checkout <start_point>".  This allows you to start a new history
-that records a set of paths similar to <start_point> by easily running
-"git commit -a" to make the root commit.
+`git checkout <start_point>`.  This allows you to start a new history
+that records a set of paths similar to `<start_point>` by easily running
+`git commit -a` to make the root commit.
 +
 This can be useful when you want to publish the tree from a commit
 without exposing its full history. You might want to do this to publish
@@ -212,17 +225,17 @@ whose full history contains proprietary or otherwise encumbered bits of
 code.
 +
 If you want to start a disconnected history that records a set of paths
-that is totally different from the one of <start_point>, then you should
+that is totally different from the one of `<start_point>`, then you should
 clear the index and the working tree right after creating the orphan
-branch by running "git rm -rf ." from the top level of the working tree.
+branch by running `git rm -rf .` from the top level of the working tree.
 Afterwards you will be ready to prepare your new files, repopulating the
 working tree, by copying them from elsewhere, extracting a tarball, etc.
 
 --ignore-skip-worktree-bits::
        In sparse checkout mode, `git checkout -- <paths>` would
-       update only entries matched by <paths> and sparse patterns
-       in $GIT_DIR/info/sparse-checkout. This option ignores
-       the sparse patterns and adds back any files in <paths>.
+       update only entries matched by `<paths>` and sparse patterns
+       in `$GIT_DIR/info/sparse-checkout`. This option ignores
+       the sparse patterns and adds back any files in `<paths>`.
 
 -m::
 --merge::
@@ -246,25 +259,25 @@ the conflicted merge in the specified paths.
 When switching branches with `--merge`, staged changes may be lost.
 
 --conflict=<style>::
-       The same as --merge option above, but changes the way the
+       The same as `--merge` option above, but changes the way the
        conflicting hunks are presented, overriding the
-       merge.conflictStyle configuration variable.  Possible values are
+       `merge.conflictStyle` configuration variable.  Possible values are
        "merge" (default) and "diff3" (in addition to what is shown by
        "merge" style, shows the original contents).
 
 -p::
 --patch::
        Interactively select hunks in the difference between the
-       <tree-ish> (or the index, if unspecified) and the working
+       `<tree-ish>` (or the index, if unspecified) and the working
        tree.  The chosen hunks are then applied in reverse to the
-       working tree (and if a <tree-ish> was specified, the index).
+       working tree (and if a `<tree-ish>` was specified, the index).
 +
 This means that you can use `git checkout -p` to selectively discard
 edits from your current working tree. See the ``Interactive Mode''
 section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
 +
 Note that this option uses the no overlay mode by default (see also
-`--[no-]overlay`), and currently doesn't support overlay mode.
+`--overlay`), and currently doesn't support overlay mode.
 
 --ignore-other-worktrees::
        `git checkout` refuses when the wanted ref is already checked
@@ -272,38 +285,42 @@ Note that this option uses the no overlay mode by default (see also
        out anyway. In other words, the ref can be held by more than one
        worktree.
 
---[no-]recurse-submodules::
-       Using --recurse-submodules will update the content of all initialized
+--overwrite-ignore::
+--no-overwrite-ignore::
+       Silently overwrite ignored files when switching branches. This
+       is the default behavior. Use `--no-overwrite-ignore` to abort
+       the operation when the new branch contains ignored files.
+
+--recurse-submodules::
+--no-recurse-submodules::
+       Using `--recurse-submodules` will update the content of all initialized
        submodules according to the commit recorded in the superproject. If
        local modifications in a submodule would be overwritten the checkout
-       will fail unless `-f` is used. If nothing (or --no-recurse-submodules)
+       will fail unless `-f` is used. If nothing (or `--no-recurse-submodules`)
        is used, the work trees of submodules will not be updated.
-       Just like linkgit:git-submodule[1], this will detach the
-       submodules HEAD.
-
---no-guess::
-       Do not attempt to create a branch if a remote tracking branch
-       of the same name exists.
+       Just like linkgit:git-submodule[1], this will detach `HEAD` of the
+       submodule.
 
---[no-]overlay::
+--overlay::
+--no-overlay::
        In the default overlay mode, `git checkout` never
        removes files from the index or the working tree.  When
        specifying `--no-overlay`, files that appear in the index and
-       working tree, but not in <tree-ish> are removed, to make them
-       match <tree-ish> exactly.
+       working tree, but not in `<tree-ish>` are removed, to make them
+       match `<tree-ish>` exactly.
 
 <branch>::
        Branch to checkout; if it refers to a branch (i.e., a name that,
        when prepended with "refs/heads/", is a valid ref), then that
        branch is checked out. Otherwise, if it refers to a valid
-       commit, your HEAD becomes "detached" and you are no longer on
+       commit, your `HEAD` becomes "detached" and you are no longer on
        any branch (see below for details).
 +
-You can use the `"@{-N}"` syntax to refer to the N-th last
+You can use the `@{-N}` syntax to refer to the N-th last
 branch/commit checked out using "git checkout" operation. You may
-also specify `-` which is synonymous to `"@{-1}"`.
+also specify `-` which is synonymous to `@{-1}`.
 +
-As a special case, you may use `"A...B"` as a shortcut for the
+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`.
 
@@ -312,7 +329,7 @@ leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
 
 <start_point>::
        The name of a commit at which to start the new branch; see
-       linkgit:git-branch[1] for details. Defaults to HEAD.
+       linkgit:git-branch[1] for details. Defaults to `HEAD`.
 +
 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
@@ -326,9 +343,9 @@ leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
 
 DETACHED HEAD
 -------------
-HEAD normally refers to a named branch (e.g. 'master'). Meanwhile, each
+`HEAD` normally refers to a named branch (e.g. `master`). Meanwhile, each
 branch refers to a specific commit. Let's look at a repo with three
-commits, one of them tagged, and with branch 'master' checked out:
+commits, one of them tagged, and with branch `master` checked out:
 
 ------------
            HEAD (refers to branch 'master')
@@ -341,10 +358,10 @@ a---b---c  branch 'master' (refers to commit 'c')
 ------------
 
 When a commit is created in this state, the branch is updated to refer to
-the new commit. Specifically, 'git commit' creates a new commit 'd', whose
-parent is commit 'c', and then updates branch 'master' to refer to new
-commit 'd'. HEAD still refers to branch 'master' and so indirectly now refers
-to commit 'd':
+the new commit. Specifically, 'git commit' creates a new commit `d`, whose
+parent is commit `c`, and then updates branch `master` to refer to new
+commit `d`. `HEAD` still refers to branch `master` and so indirectly now refers
+to commit `d`:
 
 ------------
 $ edit; git add; git commit
@@ -361,7 +378,7 @@ a---b---c---d  branch 'master' (refers to commit 'd')
 It is sometimes useful to be able to checkout a commit that is not at
 the tip of any named branch, or even to create a new commit that is not
 referenced by a named branch. Let's look at what happens when we
-checkout commit 'b' (here we show two ways this may be done):
+checkout commit `b` (here we show two ways this may be done):
 
 ------------
 $ git checkout v2.0  # or
@@ -376,9 +393,9 @@ a---b---c---d  branch 'master' (refers to commit 'd')
   tag 'v2.0' (refers to commit 'b')
 ------------
 
-Notice that regardless of which checkout command we use, HEAD now refers
-directly to commit 'b'. This is known as being in detached HEAD state.
-It means simply that HEAD refers to a specific commit, as opposed to
+Notice that regardless of which checkout command we use, `HEAD` now refers
+directly to commit `b`. This is known as being in detached `HEAD` state.
+It means simply that `HEAD` refers to a specific commit, as opposed to
 referring to a named branch. Let's see what happens when we create a commit:
 
 ------------
@@ -395,7 +412,7 @@ a---b---c---d  branch 'master' (refers to commit 'd')
   tag 'v2.0' (refers to commit 'b')
 ------------
 
-There is now a new commit 'e', but it is referenced only by HEAD. We can
+There is now a new commit `e`, but it is referenced only by `HEAD`. We can
 of course add yet another commit in this state:
 
 ------------
@@ -413,7 +430,7 @@ a---b---c---d  branch 'master' (refers to commit 'd')
 ------------
 
 In fact, we can perform all the normal Git operations. But, let's look
-at what happens when we then checkout master:
+at what happens when we then checkout `master`:
 
 ------------
 $ git checkout master
@@ -428,9 +445,9 @@ a---b---c---d  branch 'master' (refers to commit 'd')
 ------------
 
 It is important to realize that at this point nothing refers to commit
-'f'. Eventually commit 'f' (and by extension commit 'e') will be deleted
+`f`. Eventually commit `f` (and by extension commit `e`) will be deleted
 by the routine Git garbage collection process, unless we create a reference
-before that happens. If we have not yet moved away from commit 'f',
+before that happens. If we have not yet moved away from commit `f`,
 any of these will create a reference to it:
 
 ------------
@@ -439,19 +456,19 @@ $ git branch foo        <2>
 $ git tag foo           <3>
 ------------
 
-<1> creates a new branch 'foo', which refers to commit 'f', and then
-    updates HEAD to refer to branch 'foo'. In other words, we'll no longer
-    be in detached HEAD state after this command.
+<1> creates a new branch `foo`, which refers to commit `f`, and then
+    updates `HEAD` to refer to branch `foo`. In other words, we'll no longer
+    be in detached `HEAD` state after this command.
 
-<2> similarly creates a new branch 'foo', which refers to commit 'f',
-    but leaves HEAD detached.
+<2> similarly creates a new branch `foo`, which refers to commit `f`,
+    but leaves `HEAD` detached.
 
-<3> creates a new tag 'foo', which refers to commit 'f',
-    leaving HEAD detached.
+<3> creates a new tag `foo`, which refers to commit `f`,
+    leaving `HEAD` detached.
 
-If we have moved away from commit 'f', then we must first recover its object
+If we have moved away from commit `f`, then we must first recover its object
 name (typically by using git reflog), and then we can create a reference to
-it. For example, to see the last two commits to which HEAD referred, we
+it. For example, to see the last two commits to which `HEAD` referred, we
 can use either of these commands:
 
 ------------
@@ -462,12 +479,12 @@ $ git log -g -2 HEAD
 ARGUMENT DISAMBIGUATION
 -----------------------
 
-When there is only one argument given and it is not `--` (e.g. "git
-checkout abc"), and when the argument is both a valid `<tree-ish>`
-(e.g. a branch "abc" exists) and a valid `<pathspec>` (e.g. a file
+When there is only one argument given and it is not `--` (e.g. `git
+checkout abc`), and when the argument is both a valid `<tree-ish>`
+(e.g. a branch `abc` exists) and a valid `<pathspec>` (e.g. a file
 or a directory whose name is "abc" exists), Git would usually ask
 you to disambiguate.  Because checking out a branch is so common an
-operation, however, "git checkout abc" takes "abc" as a `<tree-ish>`
+operation, however, `git checkout abc` takes "abc" as a `<tree-ish>`
 in such a situation.  Use `git checkout -- <pathspec>` if you want
 to checkout these paths out of the index.
 
@@ -475,7 +492,7 @@ EXAMPLES
 --------
 
 . The following sequence checks out the `master` branch, reverts
-  the `Makefile` to two revisions back, deletes hello.c by
+  the `Makefile` to two revisions back, deletes `hello.c` by
   mistake, and gets it back from the index.
 +
 ------------
@@ -487,7 +504,7 @@ $ git checkout hello.c            <3>
 +
 <1> switch branch
 <2> take a file out of another commit
-<3> restore hello.c from the index
+<3> restore `hello.c` from the index
 +
 If you want to check out _all_ C source files out of the index,
 you can say
@@ -516,7 +533,7 @@ $ git checkout -- hello.c
 $ git checkout mytopic
 ------------
 +
-However, your "wrong" branch and correct "mytopic" branch may
+However, your "wrong" branch and correct `mytopic` branch may
 differ in files that you have modified locally, in which case
 the above checkout would fail like this:
 +
@@ -557,6 +574,11 @@ $ edit frotz
 $ git add frotz
 ------------
 
+SEE ALSO
+--------
+linkgit:git-switch[1],
+linkgit:git-restore[1]
+
 GIT
 ---
 Part of the linkgit:git[1] suite
index 754b16c..83ce51a 100644 (file)
@@ -10,9 +10,7 @@ SYNOPSIS
 [verse]
 'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff]
                  [-S[<keyid>]] <commit>...
-'git cherry-pick' --continue
-'git cherry-pick' --quit
-'git cherry-pick' --abort
+'git cherry-pick' (--continue | --skip | --abort | --quit)
 
 DESCRIPTION
 -----------
index db876f7..0028ff1 100644 (file)
@@ -63,7 +63,7 @@ OPTIONS
        still use the ignore rules given with `-e` options from the command
        line.  This allows removing all untracked
        files, including build products.  This can be used (possibly in
-       conjunction with 'git reset') to create a pristine
+       conjunction with 'git restore' or 'git reset') to create a pristine
        working directory to test a clean build.
 
 -X::
index 5fc97f1..34011c2 100644 (file)
@@ -23,7 +23,7 @@ DESCRIPTION
 
 Clones a repository into a newly created directory, creates
 remote-tracking branches for each branch in the cloned repository
-(visible using `git branch -r`), and creates and checks out an
+(visible using `git branch --remotes`), and creates and checks out an
 initial branch that is forked from the cloned repository's
 currently active branch.
 
@@ -41,8 +41,8 @@ configuration variables.
 
 OPTIONS
 -------
---local::
 -l::
+--local::
        When the repository to clone from is on a local machine,
        this flag bypasses the normal "Git aware" transport
        mechanism and clones the repository by making a copy of
@@ -63,8 +63,8 @@ Git transport instead.
        directory instead of using hardlinks. This may be desirable
        if you are trying to make a back-up of your repository.
 
---shared::
 -s::
+--shared::
        When the repository to clone is on the local machine,
        instead of using hard links, automatically setup
        `.git/objects/info/alternates` to share the objects
@@ -81,13 +81,13 @@ 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.
 +
-Note that running `git repack` without the `-l` option in a repository
-cloned with `-s` will copy objects from the source repository into a pack
-in the cloned repository, removing the disk space savings of `clone -s`.
-It is safe, however, to run `git gc`, which uses the `-l` option by
+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
+in the cloned repository, removing the disk space savings of `clone --shared`.
+It is safe, however, to run `git gc`, which uses the `--local` option by
 default.
 +
-If you want to break the dependency of a repository cloned with `-s` on
+If you want to break the dependency of a repository cloned with `--shared` on
 its source repository, you can simply run `git repack -a` to copy all
 objects from the source repository into a pack in the cloned repository.
 
@@ -116,19 +116,19 @@ objects from the source repository into a pack in the cloned repository.
        same repository, and this option can be used to stop the
        borrowing.
 
---quiet::
 -q::
+--quiet::
        Operate quietly.  Progress is not reported to the standard
        error stream.
 
---verbose::
 -v::
+--verbose::
        Run verbosely. Does not affect the reporting of progress status
        to the standard error stream.
 
 --progress::
        Progress status is reported on the standard error stream
-       by default when it is attached to a terminal, unless -q
+       by default when it is attached to a terminal, unless `--quiet`
        is specified. This flag forces progress status even if the
        standard error stream is not directed to a terminal.
 
@@ -140,15 +140,15 @@ objects from the source repository into a pack in the cloned repository.
        When multiple `--server-option=<option>` are given, they are all
        sent to the other side in the order listed on the command line.
 
---no-checkout::
 -n::
+--no-checkout::
        No checkout of HEAD is performed after the clone is complete.
 
 --bare::
        Make a 'bare' Git repository.  That is, instead of
        creating `<directory>` and placing the administrative
        files in `<directory>/.git`, make the `<directory>`
-       itself the `$GIT_DIR`. This obviously implies the `-n`
+       itself the `$GIT_DIR`. This obviously implies the `--no-checkout`
        because there is nowhere to check out the working tree.
        Also the branch heads at the remote are copied directly
        to corresponding local branch heads, without mapping
@@ -164,13 +164,13 @@ objects from the source repository into a pack in the cloned repository.
        that all these refs are overwritten by a `git remote update` in the
        target repository.
 
---origin <name>::
 -o <name>::
+--origin <name>::
        Instead of using the remote name `origin` to keep track
        of the upstream repository, use `<name>`.
 
---branch <name>::
 -b <name>::
+--branch <name>::
        Instead of pointing the newly created HEAD to the branch pointed
        to by the cloned repository's HEAD, point to `<name>` branch
        instead. In a non-bare repository, this is the branch that will
@@ -178,8 +178,8 @@ objects from the source repository into a pack in the cloned repository.
        `--branch` can also take tags and detaches the HEAD at that commit
        in the resulting repository.
 
---upload-pack <upload-pack>::
 -u <upload-pack>::
+--upload-pack <upload-pack>::
        When given, and the repository to clone from is accessed
        via ssh, this specifies a non-default path for the command
        run on the other end.
@@ -188,8 +188,8 @@ objects from the source repository into a pack in the cloned repository.
        Specify the directory from which templates will be used;
        (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
 
---config <key>=<value>::
 -c <key>=<value>::
+--config <key>=<value>::
        Set a configuration variable in the newly-created repository;
        this takes effect immediately after the repository is
        initialized, but before the remote history is fetched or any
index 624470e..eb5e786 100644 (file)
@@ -10,7 +10,7 @@ SYNOPSIS
 --------
 [verse]
 'git commit-graph read' [--object-dir <dir>]
-'git commit-graph verify' [--object-dir <dir>]
+'git commit-graph verify' [--object-dir <dir>] [--shallow]
 'git commit-graph write' <options> [--object-dir <dir>]
 
 
@@ -26,7 +26,7 @@ OPTIONS
        Use given directory for the location of packfiles and commit-graph
        file. This parameter exists to specify the location of an alternate
        that only has the objects directory, not a full `.git` directory. The
-       commit-graph file is expected to be at `<dir>/info/commit-graph` and
+       commit-graph file is expected to be in the `<dir>/info` directory and
        the packfiles are expected to be in `<dir>/pack`.
 
 
@@ -51,6 +51,25 @@ or `--stdin-packs`.)
 +
 With the `--append` option, include all commits that are present in the
 existing commit-graph file.
++
+With the `--split` option, write the commit-graph as a chain of multiple
+commit-graph files stored in `<dir>/info/commit-graphs`. The new commits
+not already in the commit-graph are added in a new "tip" file. This file
+is merged with the existing file if the following merge conditions are
+met:
++
+* If `--size-multiple=<X>` is not specified, let `X` equal 2. If the new
+tip file would have `N` commits and the previous tip has `M` commits and
+`X` times `N` is greater than  `M`, instead merge the two files into a
+single file.
++
+* If `--max-commits=<M>` is specified with `M` a positive integer, and the
+new tip file would have more than `M` commits, then instead merge the new
+tip with the previous tip.
++
+Finally, if `--expire-time=<datetime>` is not specified, let `datetime`
+be the current time. After writing the split commit-graph, delete all
+unused commit-graph whose modified times are older than `datetime`.
 
 'read'::
 
@@ -61,6 +80,9 @@ Used for debugging purposes.
 
 Read the commit-graph file and verify its contents against the object
 database. Used to check for corrupted data.
++
+With the `--shallow` option, only check the tip commit-graph file in
+a chain of split commit-graphs.
 
 
 EXAMPLES
index a85c2c2..7628193 100644 (file)
@@ -359,7 +359,7 @@ When recording your own work, the contents of modified files in
 your working tree are temporarily stored to a staging area
 called the "index" with 'git add'.  A file can be
 reverted back, only in the index but not in the working tree,
-to that of the last commit with `git reset HEAD -- <file>`,
+to that of the last commit with `git restore --staged <file>`,
 which effectively reverts 'git add' and prevents the changes to
 this file from participating in the next commit.  After building
 the state to be committed incrementally with these commands,
index f98b7c6..79e22b1 100644 (file)
@@ -232,7 +232,7 @@ write so it might not be enough to grant the users using
 'git-cvsserver' write access to the database file without granting
 them write access to the directory, too.
 
-The database can not be reliably regenerated in a
+The database cannot be reliably regenerated in a
 consistent form after the branch it is tracking has changed.
 Example: For merged branches, 'git-cvsserver' only tracks
 one branch of development, and after a 'git merge' an
index 11427ac..784e934 100644 (file)
@@ -17,9 +17,9 @@ This program dumps the given revisions in a form suitable to be piped
 into 'git fast-import'.
 
 You can use it as a human-readable bundle replacement (see
-linkgit:git-bundle[1]), or as a kind of an interactive
-'git filter-branch'.
-
+linkgit:git-bundle[1]), or as a format that can be edited before being
+fed to 'git fast-import' in order to do history rewrites (an ability
+relied on by tools like 'git filter-repo').
 
 OPTIONS
 -------
@@ -116,7 +116,7 @@ marks the same across runs.
        and will make master{tilde}4 no longer have master{tilde}5 as
        a parent (though both the old master{tilde}4 and new
        master{tilde}4 will have all the same files).  Use
-       --reference-excluded-parents to instead have the the stream
+       --reference-excluded-parents to instead have the stream
        refer to commits in the excluded range of history by their
        sha1sum.  Note that the resulting stream can only be used by a
        repository which already contains the necessary parent
index 7baf9e4..0bb2762 100644 (file)
@@ -391,7 +391,7 @@ change to the project.
        ('encoding' SP <encoding>)?
        data
        ('from' SP <commit-ish> LF)?
-       ('merge' SP <commit-ish> LF)?
+       ('merge' SP <commit-ish> LF)*
        (filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
        LF?
 ....
@@ -425,7 +425,7 @@ the same commit, as `filedeleteall` wipes the branch clean (see below).
 
 The `LF` after the command is optional (it used to be required).  Note
 that for reasons of backward compatibility, if the commit ends with a
-`data` command (i.e. it has has no `from`, `merge`, `filemodify`,
+`data` command (i.e. it has no `from`, `merge`, `filemodify`,
 `filedelete`, `filecopy`, `filerename`, `filedeleteall` or
 `notemodify` commands) then two `LF` commands may appear at the end of
 the command instead of just one.
index 266d63c..5b1909f 100644 (file)
@@ -262,7 +262,7 @@ This updates (or creates, as necessary) branches `pu` and `tmp` in
 the local repository by fetching from the branches (respectively)
 `pu` and `maint` from the remote repository.
 +
-The `pu` branch will be updated even if it is does not fast-forward,
+The `pu` branch will be updated even if it does not fast-forward,
 because it is prefixed with a plus sign; `tmp` will not be.
 
 * Peek at a remote's branch, without configuring the remote in your local
@@ -285,7 +285,7 @@ BUGS
 ----
 Using --recurse-submodules can only fetch new commits in already checked
 out submodules right now. When e.g. upstream added a new submodule in the
-just fetched commits of the superproject the submodule itself can not be
+just fetched commits of the superproject the submodule itself cannot be
 fetched, making it impossible to check out that submodule later without
 having to do a fetch again. This is expected to be fixed in a future Git
 version.
index 6b53dd7..5876598 100644 (file)
@@ -16,6 +16,19 @@ SYNOPSIS
        [--original <namespace>] [-d <directory>] [-f | --force]
        [--state-branch <branch>] [--] [<rev-list options>...]
 
+WARNING
+-------
+'git filter-branch' has a plethora of pitfalls that can produce non-obvious
+manglings of the intended history rewrite (and can leave you with little
+time to investigate such problems since it has such abysmal performance).
+These safety and performance issues cannot be backward compatibly fixed and
+as such, its use is not recommended.  Please use an alternative history
+filtering tool such as https://github.com/newren/git-filter-repo/[git
+filter-repo].  If you still need to use 'git filter-branch', please
+carefully read <<SAFETY>> (and <<PERFORMANCE>>) to learn about the land
+mines of filter-branch, and then vigilantly avoid as many of the hazards
+listed there as reasonably possible.
+
 DESCRIPTION
 -----------
 Lets you rewrite Git revision history by rewriting the branches mentioned
@@ -445,36 +458,236 @@ warned.
   (or if your git-gc is not new enough to support arguments to
   `--prune`, use `git repack -ad; git prune` instead).
 
-NOTES
------
-
-git-filter-branch allows you to make complex shell-scripted rewrites
-of your Git history, but you probably don't need this flexibility if
-you're simply _removing unwanted data_ like large files or passwords.
-For those operations you may want to consider
-http://rtyley.github.io/bfg-repo-cleaner/[The BFG Repo-Cleaner],
-a JVM-based alternative to git-filter-branch, typically at least
-10-50x faster for those use-cases, and with quite different
-characteristics:
-
-* Any particular version of a file is cleaned exactly _once_. The BFG,
-  unlike git-filter-branch, does not give you the opportunity to
-  handle a file differently based on where or when it was committed
-  within your history. This constraint gives the core performance
-  benefit of The BFG, and is well-suited to the task of cleansing bad
-  data - you don't care _where_ the bad data is, you just want it
-  _gone_.
-
-* By default The BFG takes full advantage of multi-core machines,
-  cleansing commit file-trees in parallel. git-filter-branch cleans
-  commits sequentially (i.e. in a single-threaded manner), though it
-  _is_ possible to write filters that include their own parallelism,
-  in the scripts executed against each commit.
-
-* The http://rtyley.github.io/bfg-repo-cleaner/#examples[command options]
-  are much more restrictive than git-filter branch, and dedicated just
-  to the tasks of removing unwanted data- e.g:
-  `--strip-blobs-bigger-than 1M`.
+[[PERFORMANCE]]
+PERFORMANCE
+-----------
+
+The performance of git-filter-branch is glacially slow; its design makes it
+impossible for a backward-compatible implementation to ever be fast:
+
+* In editing files, git-filter-branch by design checks out each and
+every commit as it existed in the original repo.  If your repo has 10\^5
+files and 10\^5 commits, but each commit only modifies 5 files, then
+git-filter-branch will make you do 10\^10 modifications, despite only
+having (at most) 5*10^5 unique blobs.
+
+* If you try and cheat and try to make git-filter-branch only work on
+files modified in a commit, then two things happen
+
+  ** you run into problems with deletions whenever the user is simply
+     trying to rename files (because attempting to delete files that
+     don't exist looks like a no-op; it takes some chicanery to remap
+     deletes across file renames when the renames happen via arbitrary
+     user-provided shell)
+
+  ** even if you succeed at the map-deletes-for-renames chicanery, you
+     still technically violate backward compatibility because users are
+     allowed to filter files in ways that depend upon topology of
+     commits instead of filtering solely based on file contents or names
+     (though this has not been observed in the wild).
+
+* Even if you don't need to edit files but only want to e.g. rename or
+remove some and thus can avoid checking out each file (i.e. you can use
+--index-filter), you still are passing shell snippets for your filters.
+This means that for every commit, you have to have a prepared git repo
+where those filters can be run.  That's a significant setup.
+
+* Further, several additional files are created or updated per commit by
+git-filter-branch.  Some of these are for supporting the convenience
+functions provided by git-filter-branch (such as map()), while others
+are for keeping track of internal state (but could have also been
+accessed by user filters; one of git-filter-branch's regression tests
+does so).  This essentially amounts to using the filesystem as an IPC
+mechanism between git-filter-branch and the user-provided filters.
+Disks tend to be a slow IPC mechanism, and writing these files also
+effectively represents a forced synchronization point between separate
+processes that we hit with every commit.
+
+* The user-provided shell commands will likely involve a pipeline of
+commands, resulting in the creation of many processes per commit.
+Creating and running another process takes a widely varying amount of
+time between operating systems, but on any platform it is very slow
+relative to invoking a function.
+
+* git-filter-branch itself is written in shell, which is kind of slow.
+This is the one performance issue that could be backward-compatibly
+fixed, but compared to the above problems that are intrinsic to the
+design of git-filter-branch, the language of the tool itself is a
+relatively minor issue.
+
+  ** Side note: Unfortunately, people tend to fixate on the
+     written-in-shell aspect and periodically ask if git-filter-branch
+     could be rewritten in another language to fix the performance
+     issues.  Not only does that ignore the bigger intrinsic problems
+     with the design, it'd help less than you'd expect: if
+     git-filter-branch itself were not shell, then the convenience
+     functions (map(), skip_commit(), etc) and the `--setup` argument
+     could no longer be executed once at the beginning of the program
+     but would instead need to be prepended to every user filter (and
+     thus re-executed with every commit).
+
+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
+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
+git-filter-branch, it at least ameloriates the performance issues a
+little.
+
+[[SAFETY]]
+SAFETY
+------
+
+git-filter-branch is riddled with gotchas resulting in various ways to
+easily corrupt repos or end up with a mess worse than what you started
+with:
+
+* Someone can have a set of "working and tested filters" which they
+document or provide to a coworker, who then runs them on a different OS
+where the same commands are not working/tested (some examples in the
+git-filter-branch manpage are also affected by this).  BSD vs. GNU
+userland differences can really bite.  If lucky, error messages are
+spewed.  But just as likely, the commands either don't do the filtering
+requested, or silently corrupt by making some unwanted change.  The
+unwanted change may only affect a few commits, so it's not necessarily
+obvious either.  (The fact that problems won't necessarily be obvious
+means they are likely to go unnoticed until the rewritten history is in
+use for quite a while, at which point it's really hard to justify
+another flag-day for another rewrite.)
+
+* Filenames with spaces are often mishandled by shell snippets since
+they cause problems for shell pipelines.  Not everyone is familiar with
+find -print0, xargs -0, git-ls-files -z, etc.  Even people who are
+familiar with these may assume such flags are not relevant because
+someone else renamed any such files in their repo back before the person
+doing the filtering joined the project.  And often, even those familiar
+with handling arguments with spaces may not do so just because they
+aren't in the mindset of thinking about everything that could possibly
+go wrong.
+
+* Non-ascii filenames can be silently removed despite being in a desired
+directory.  Keeping only wanted paths is often done using pipelines like
+`git ls-files | grep -v ^WANTED_DIR/ | xargs git rm`.  ls-files will
+only quote filenames if needed, so folks may not notice that one of the
+files didn't match the regex (at least not until it's much too late).
+Yes, someone who knows about core.quotePath can avoid this (unless they
+have other special characters like \t, \n, or "), and people who use
+ls-files -z with something other than grep can avoid this, but that
+doesn't mean they will.
+
+* Similarly, when moving files around, one can find that filenames with
+non-ascii or special characters end up in a different directory, one
+that includes a double quote character.  (This is technically the same
+issue as above with quoting, but perhaps an interesting different way
+that it can and has manifested as a problem.)
+
+* It's far too easy to accidentally mix up old and new history.  It's
+still possible with any tool, but git-filter-branch almost invites it.
+If lucky, the only downside is users getting frustrated that they don't
+know how to shrink their repo and remove the old stuff.  If unlucky,
+they merge old and new history and end up with multiple "copies" of each
+commit, some of which have unwanted or sensitive files and others which
+don't.  This comes about in multiple different ways:
+
+  ** the default to only doing a partial history rewrite ('--all' is not
+     the default and few examples show it)
+
+  ** the fact that there's no automatic post-run cleanup
+
+  ** the fact that --tag-name-filter (when used to rename tags) doesn't
+     remove the old tags but just adds new ones with the new name
+
+  ** the fact that little educational information is provided to inform
+     users of the ramifications of a rewrite and how to avoid mixing old
+     and new history.  For example, this man page discusses how users
+     need to understand that they need to rebase their changes for all
+     their branches on top of new history (or delete and reclone), but
+     that's only one of multiple concerns to consider.  See the
+     "DISCUSSION" section of the git filter-repo manual page for more
+     details.
+
+* Annotated tags can be accidentally converted to lightweight tags, due
+to either of two issues:
+
+  ** Someone can do a history rewrite, realize they messed up, restore
+     from the backups in refs/original/, and then redo their
+     git-filter-branch command.  (The backup in refs/original/ is not a
+     real backup; it dereferences tags first.)
+
+  ** Running git-filter-branch with either --tags or --all in your
+     <rev-list options>.  In order to retain annotated tags as
+     annotated, you must use --tag-name-filter (and must not have
+     restored from refs/original/ in a previously botched rewrite).
+
+* Any commit messages that specify an encoding will become corrupted
+by the rewrite; git-filter-branch ignores the encoding, takes the original
+bytes, and feeds it to commit-tree without telling it the proper
+encoding.  (This happens whether or not --msg-filter is used.)
+
+* Commit messages (even if they are all UTF-8) by default become
+corrupted due to not being updated -- any references to other commit
+hashes in commit messages will now refer to no-longer-extant commits.
+
+* There are no facilities for helping users find what unwanted crud they
+should delete, which means they are much more likely to have incomplete
+or partial cleanups that sometimes result in confusion and people
+wasting time trying to understand.  (For example, folks tend to just
+look for big files to delete instead of big directories or extensions,
+and once they do so, then sometime later folks using the new repository
+who are going through history will notice a build artifact directory
+that has some files but not others, or a cache of dependencies
+(node_modules or similar) which couldn't have ever been functional since
+it's missing some files.)
+
+* If --prune-empty isn't specified, then the filtering process can
+create hoards of confusing empty commits
+
+* If --prune-empty is specified, then intentionally placed empty
+commits from before the filtering operation are also pruned instead of
+just pruning commits that became empty due to filtering rules.
+
+* If --prune empty is specified, sometimes empty commits are missed
+and left around anyway (a somewhat rare bug, but it happens...)
+
+* A minor issue, but users who have a goal to update all names and
+emails in a repository may be led to --env-filter which will only update
+authors and committers, missing taggers.
+
+* If the user provides a --tag-name-filter that maps multiple tags to
+the same name, no warning or error is provided; git-filter-branch simply
+overwrites each tag in some undocumented pre-defined order resulting in
+only one tag at the end.  (A git-filter-branch regression test requires
+this surprising behavior.)
+
+Also, the poor performance of git-filter-branch often leads to safety
+issues:
+
+* Coming up with the correct shell snippet to do the filtering you want
+is sometimes difficult unless you're just doing a trivial modification
+such as deleting a couple files.  Unfortunately, people often learn if
+the snippet is right or wrong by trying it out, but the rightness or
+wrongness can vary depending on special circumstances (spaces in
+filenames, non-ascii filenames, funny author names or emails, invalid
+timezones, presence of grafts or replace objects, etc.), meaning they
+may have to wait a long time, hit an error, then restart.  The
+performance of git-filter-branch is so bad that this cycle is painful,
+reducing the time available to carefully re-check (to say nothing about
+what it does to the patience of the person doing the rewrite even if
+they do technically have more time available).  This problem is extra
+compounded because errors from broken filters may not be shown for a
+long time and/or get lost in a sea of output.  Even worse, broken
+filters often just result in silent incorrect rewrites.
+
+* To top it all off, even when users finally find working commands, they
+naturally want to share them.  But they may be unaware that their repo
+didn't have some special cases that someone else's does.  So, when
+someone else with a different repository runs the same commands, they
+get hit by the problems above.  Or, the user just runs commands that
+really were vetted for special cases, but they run it on a different OS
+where it doesn't work, as noted above.
 
 GIT
 ---
index 774cecc..6dcd39f 100644 (file)
@@ -214,6 +214,11 @@ symref::
        `:lstrip` and `:rstrip` options in the same way as `refname`
        above.
 
+worktreepath::
+       The absolute path to the worktree in which the ref is checked
+       out, if it is checked out in any linked worktree. Empty string
+       otherwise.
+
 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.
index 9ce5b8a..0ac56f4 100644 (file)
@@ -17,9 +17,9 @@ SYNOPSIS
                   [--signature-file=<file>]
                   [-n | --numbered | -N | --no-numbered]
                   [--start-number <n>] [--numbered-files]
-                  [--in-reply-to=Message-Id] [--suffix=.<sfx>]
+                  [--in-reply-to=<message id>] [--suffix=.<sfx>]
                   [--ignore-if-in-upstream]
-                  [--rfc] [--subject-prefix=Subject-Prefix]
+                  [--rfc] [--subject-prefix=<subject prefix>]
                   [(--reroll-count|-v) <n>]
                   [--to=<email>] [--cc=<email>]
                   [--[no-]cover-letter] [--quiet]
@@ -159,9 +159,9 @@ Beware that the default for 'git send-email' is to thread emails
 itself.  If you want `git format-patch` to take care of threading, you
 will want to ensure that threading is disabled for `git send-email`.
 
---in-reply-to=Message-Id::
+--in-reply-to=<message id>::
        Make the first mail (or all the mails with `--no-thread`) appear as a
-       reply to the given Message-Id, which avoids breaking threads to
+       reply to the given <message id>, which avoids breaking threads to
        provide a new patch series.
 
 --ignore-if-in-upstream::
@@ -171,9 +171,9 @@ will want to ensure that threading is disabled for `git send-email`.
        patches being generated, and any patch that matches is
        ignored.
 
---subject-prefix=<Subject-Prefix>::
+--subject-prefix=<subject prefix>::
        Instead of the standard '[PATCH]' prefix in the subject
-       line, instead use '[<Subject-Prefix>]'. This
+       line, instead use '[<subject prefix>]'. This
        allows for useful naming of a patch series, and can be
        combined with the `--numbered` option.
 
@@ -314,7 +314,8 @@ you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`.
 --base=<commit>::
        Record the base tree information to identify the state the
        patch series applies to.  See the BASE TREE INFORMATION section
-       below for details.
+       below for details. If <commit> is "auto", a base commit is
+       automatically chosen.
 
 --root::
        Treat the revision argument as a <revision range>, even if it
@@ -330,8 +331,9 @@ CONFIGURATION
 -------------
 You can specify extra mail header lines to be added to each message,
 defaults for the subject prefix and file suffix, number patches when
-outputting more than one patch, add "To" or "Cc:" headers, configure
-attachments, and sign off patches with configuration variables.
+outputting more than one patch, add "To:" or "Cc:" headers, configure
+attachments, change the patch output directory, and sign off patches
+with configuration variables.
 
 ------------
 [format]
@@ -343,7 +345,8 @@ attachments, and sign off patches with configuration variables.
        cc = <email>
        attach [ = mime-boundary-string ]
        signOff = true
-       coverletter = auto
+       outputDirectory = <directory>
+       coverLetter = auto
 ------------
 
 
@@ -426,8 +429,8 @@ One way to test if your MUA is set up correctly is:
 * Apply it:
 
     $ git fetch <project> master:test-apply
-    $ git checkout test-apply
-    $ git reset --hard
+    $ git switch test-apply
+    $ git restore --source=HEAD --staged --worktree :/
     $ git am a.patch
 
 If it does not apply correctly, there can be various reasons.
index e0eae64..d72d15b 100644 (file)
@@ -104,6 +104,11 @@ care about this output and want to speed it up further.
        progress status even if the standard error stream is not
        directed to a terminal.
 
+CONFIGURATION
+-------------
+
+include::config/fsck.txt[]
+
 DISCUSSION
 ----------
 
index 247f765..0c114ad 100644 (file)
@@ -115,15 +115,14 @@ NOTES
 -----
 
 'git gc' tries very hard not to delete objects that are referenced
-anywhere in your repository. In
-particular, it will keep not only objects referenced by your current set
-of branches and tags, but also objects referenced by the index,
-remote-tracking branches, refs saved by 'git filter-branch' in
-refs/original/, reflogs (which may reference commits in branches
-that were later amended or rewound), and anything else in the refs/* namespace.
-If you are expecting some objects to be deleted and they aren't, check
-all of those locations and decide whether it makes sense in your case to
-remove those references.
+anywhere in your repository. In particular, it will keep not only
+objects referenced by your current set of branches and tags, but also
+objects referenced by the index, remote-tracking branches, notes saved
+by 'git notes' under refs/notes/, reflogs (which may reference commits
+in branches that were later amended or rewound), and anything else in
+the refs/* namespace.  If you are expecting some objects to be deleted
+and they aren't, check all of those locations and decide whether it
+makes sense in your case to remove those references.
 
 On the other hand, when 'git gc' runs concurrently with another process,
 there is a risk of it deleting an object that the other process is using
index b02e922..b406bc4 100644 (file)
@@ -49,7 +49,7 @@ OPTIONS
        Print out the ref name given on the command line by which each
        commit was reached.
 
---use-mailmap::
+--[no-]use-mailmap::
        Use mailmap file to map author and committer names and email
        addresses to canonical real names and email addresses. See
        linkgit:git-shortlog[1].
index 9f07f4f..261d5c1 100644 (file)
@@ -149,7 +149,7 @@ instead.
 Discussion on fork-point mode
 -----------------------------
 
-After working on the `topic` branch created with `git checkout -b
+After working on the `topic` branch created with `git switch -c
 topic origin/master`, the history of remote-tracking branch
 `origin/master` may have been rewound and rebuilt, leading to a
 history of this shape:
index c01cfa6..092529c 100644 (file)
@@ -10,11 +10,10 @@ SYNOPSIS
 --------
 [verse]
 'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
-       [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
+       [--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
        [--[no-]allow-unrelated-histories]
        [--[no-]rerere-autoupdate] [-m <msg>] [-F <file>] [<commit>...]
-'git merge' --abort
-'git merge' --continue
+'git merge' (--continue | --abort | --quit)
 
 DESCRIPTION
 -----------
@@ -88,6 +87,11 @@ will be appended to the specified message.
        Allow the rerere mechanism to update the index with the
        result of auto-conflict resolution if possible.
 
+--overwrite-ignore::
+--no-overwrite-ignore::
+       Silently overwrite ignored files from the merge result. This
+       is the default behavior. Use `--no-overwrite-ignore` to abort.
+
 --abort::
        Abort the current conflict resolution process, and
        try to reconstruct the pre-merge state.
index f7778a2..233b2b7 100644 (file)
@@ -9,7 +9,7 @@ git-multi-pack-index - Write and verify multi-pack-indexes
 SYNOPSIS
 --------
 [verse]
-'git multi-pack-index' [--object-dir=<dir>] <verb>
+'git multi-pack-index' [--object-dir=<dir>] <subcommand>
 
 DESCRIPTION
 -----------
@@ -23,13 +23,35 @@ OPTIONS
        `<dir>/packs/multi-pack-index` for the current MIDX file, and
        `<dir>/packs` for the pack-files to index.
 
+The following subcommands are available:
+
 write::
-       When given as the verb, write a new MIDX file to
-       `<dir>/packs/multi-pack-index`.
+       Write a new MIDX file.
 
 verify::
-       When given as the verb, verify the contents of the MIDX file
-       at `<dir>/packs/multi-pack-index`.
+       Verify the contents of the MIDX file.
+
+expire::
+       Delete the pack-files that are tracked  by the MIDX file, but
+       have no objects referenced by the MIDX. Rewrite the MIDX file
+       afterward to remove all references to these pack-files.
+
+repack::
+       Create a new pack-file containing objects in small pack-files
+       referenced by the multi-pack-index. If the size given by the
+       `--batch-size=<size>` argument is zero, then create a pack
+       containing all objects referenced by the multi-pack-index. For
+       a non-zero batch size, Select the pack-files by examining packs
+       from oldest-to-newest, computing the "expected size" by counting
+       the number of objects in the pack referenced by the
+       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.
 
 
 EXAMPLES
index e45f3e6..fecdf26 100644 (file)
@@ -131,7 +131,7 @@ depth is 4095.
 --keep-pack=<pack-name>::
        This flag causes an object already in the given pack to be
        ignored, even if it would have otherwise been
-       packed. `<pack-name>` is the the pack file name without
+       packed. `<pack-name>` is the pack file name without
        leading directory (e.g. `pack-123.pack`). The option could be
        specified multiple times to keep multiple packs.
 
index a5e9501..dfb901f 100644 (file)
@@ -249,7 +249,7 @@ BUGS
 ----
 Using --recurse-submodules can only fetch new commits in already checked
 out submodules right now. When e.g. upstream added a new submodule in the
-just fetched commits of the superproject the submodule itself can not be
+just fetched commits of the superproject the submodule itself cannot be
 fetched, making it impossible to check out that submodule later without
 having to do a fetch again. This is expected to be fixed in a future Git
 version.
index 6a8a0d9..3b80534 100644 (file)
@@ -75,7 +75,7 @@ without any `<refspec>` on the command line.  Otherwise, missing
 +
 If <dst> doesn't start with `refs/` (e.g. `refs/heads/master`) we will
 try to infer where in `refs/*` on the destination <repository> it
-belongs based on the the type of <src> being pushed and whether <dst>
+belongs based on the type of <src> being pushed and whether <dst>
 is ambiguous.
 +
 --
index 5e4e927..639a417 100644 (file)
@@ -8,16 +8,16 @@ git-rebase - Reapply commits on top of another base tip
 SYNOPSIS
 --------
 [verse]
-'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]
-       [<upstream> [<branch>]]
+'git rebase' [-i | --interactive] [<options>] [--exec <cmd>]
+       [--onto <newbase> | --keep-base] [<upstream> [<branch>]]
 'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]
        --root [<branch>]
-'git rebase' --continue | --skip | --abort | --quit | --edit-todo | --show-current-patch
+'git rebase' (--continue | --skip | --abort | --quit | --edit-todo | --show-current-patch)
 
 DESCRIPTION
 -----------
 If <branch> is specified, 'git rebase' will perform an automatic
-`git checkout <branch>` before doing anything else.  Otherwise
+`git switch <branch>` before doing anything else.  Otherwise
 it remains on the current branch.
 
 If <upstream> is not specified, the upstream configured in
@@ -217,6 +217,24 @@ 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.
 
+--keep-base::
+       Set the starting point at which to create the new commits to the
+       merge base of <upstream> <branch>. Running
+       'git rebase --keep-base <upstream> <branch>' is equivalent to
+       running 'git rebase --onto <upstream>... <upstream>'.
++
+This option is useful in the case where one is developing a feature on
+top of an upstream branch. While the feature is being worked on, the
+upstream branch may advance and it may not be the best idea to keep
+rebasing on top of the upstream but to keep the base commit as-is.
++
+Although both this option and --fork-point find the merge base between
+<upstream> and <branch>, this option uses the merge base as the _starting
+point_ on which new commits will be created, whereas --fork-point uses
+the merge base to determine the _set of commits_ which will be rebased.
++
+See also INCOMPATIBLE OPTIONS below.
+
 <upstream>::
        Upstream branch to compare against.  May be any valid commit,
        not just an existing branch name. Defaults to the configured
@@ -369,6 +387,10 @@ ends up being empty, the <upstream> will be used as a fallback.
 +
 If either <upstream> or --root is given on the command line, then the
 default is `--no-fork-point`, otherwise the default is `--fork-point`.
++
+If your branch was based on <upstream> but <upstream> was rewound and
+your branch contains commits which were dropped, this option can be used
+with `--keep-base` in order to drop those commits from your branch.
 
 --ignore-whitespace::
 --whitespace=<option>::
@@ -543,8 +565,8 @@ In addition, the following pairs of options are incompatible:
  * --preserve-merges and --interactive
  * --preserve-merges and --signoff
  * --preserve-merges and --rebase-merges
- * --rebase-merges and --strategy
- * --rebase-merges and --strategy-option
+ * --keep-base and --onto
+ * --keep-base and --root
 
 BEHAVIORAL DIFFERENCES
 -----------------------
@@ -832,7 +854,8 @@ Hard case: The changes are not the same.::
        This happens if the 'subsystem' rebase had conflicts, or used
        `--interactive` to omit, edit, squash, or fixup commits; or
        if the upstream used one of `commit --amend`, `reset`, or
-       `filter-branch`.
+       a full history rewriting command like
+       https://github.com/newren/git-filter-repo[`filter-repo`].
 
 
 The easy case
@@ -870,7 +893,7 @@ NOTE: While an "easy case recovery" sometimes appears to be successful
       --interactive` will be **resurrected**!
 
 The idea is to manually tell 'git rebase' "where the old 'subsystem'
-ended and your 'topic' began", that is, what the old merge-base
+ended and your 'topic' began", that is, what the old merge base
 between them was.  You will have to find a way to name the last commit
 of the old 'subsystem', for example:
 
index 0cad37f..9659abb 100644 (file)
@@ -230,7 +230,7 @@ $ git branch -r
   staging/master
   staging/staging-linus
   staging/staging-next
-$ git checkout -b staging staging/master
+$ git switch -c staging staging/master
 ...
 ------------
 
index aa0cc8b..92f146d 100644 (file)
@@ -142,7 +142,7 @@ depth is 4095.
 
 --keep-pack=<pack-name>::
        Exclude the given pack from repacking. This is the equivalent
-       of having `.keep` file on the pack. `<pack-name>` is the the
+       of having `.keep` file on the pack. `<pack-name>` is the
        pack file name without leading directory (e.g. `pack-123.pack`).
        The option could be specified multiple times to keep multiple
        packs.
index 246dc99..f271d75 100644 (file)
@@ -123,10 +123,10 @@ The following format are available:
 CREATING REPLACEMENT OBJECTS
 ----------------------------
 
-linkgit:git-filter-branch[1], linkgit:git-hash-object[1] and
-linkgit:git-rebase[1], among other git commands, can be used to create
-replacement objects from existing objects. The `--edit` option can
-also be used with 'git replace' to create a replacement object by
+linkgit:git-hash-object[1], linkgit:git-rebase[1], and
+https://github.com/newren/git-filter-repo[git-filter-repo], among other git commands, can be used to
+create replacement objects from existing objects. The `--edit` option
+can also be used with 'git replace' to create a replacement object by
 editing an existing object.
 
 If you want to replace many blobs, trees or commits that are part of a
@@ -148,13 +148,13 @@ pending objects.
 SEE ALSO
 --------
 linkgit:git-hash-object[1]
-linkgit:git-filter-branch[1]
 linkgit:git-rebase[1]
 linkgit:git-tag[1]
 linkgit:git-branch[1]
 linkgit:git-commit[1]
 linkgit:git-var[1]
 linkgit:git[1]
+https://github.com/newren/git-filter-repo[git-filter-repo]
 
 GIT
 ---
index 95763d7..4cfc883 100644 (file)
@@ -91,7 +91,7 @@ For such a test, you need to merge master and topic somehow.
 One way to do it is to pull master into the topic branch:
 
 ------------
-       $ git checkout topic
+       $ git switch topic
        $ git merge master
 
               o---*---o---+ topic
@@ -113,10 +113,10 @@ the upstream might have been advanced since the test merge `+`,
 in which case the final commit graph would look like this:
 
 ------------
-       $ git checkout topic
+       $ git switch topic
        $ git merge master
        $ ... work on both topic and master branches
-       $ git checkout master
+       $ git switch master
        $ git merge topic
 
               o---*---o---+---o---o topic
@@ -136,11 +136,11 @@ merges, you could blow away the test merge, and keep building on
 top of the tip before the test merge:
 
 ------------
-       $ git checkout topic
+       $ git switch topic
        $ git merge master
        $ git reset --hard HEAD^ ;# rewind the test merge
        $ ... work on both topic and master branches
-       $ git checkout master
+       $ git switch master
        $ git merge topic
 
               o---*---o-------o---o topic
index 26e746c..97e0544 100644 (file)
@@ -25,12 +25,13 @@ The `<tree-ish>`/`<commit>` defaults to `HEAD` in all forms.
        the current branch.)
 +
 This means that `git reset <paths>` is the opposite of `git add
-<paths>`.
+<paths>`. This command is equivalent to
+`git restore [--source=<tree-ish>] --staged <paths>...`.
 +
 After running `git reset <paths>` to update the index entry, you can
-use linkgit:git-checkout[1] to check the contents out of the index to
-the working tree.
-Alternatively, using linkgit:git-checkout[1] and specifying a commit, you
+use linkgit:git-restore[1] to check the contents out of the index to
+the working tree. Alternatively, using linkgit:git-restore[1]
+and specifying a commit with `--source`, you
 can copy the contents of a path out of a commit to the index and to the
 working tree in one go.
 
@@ -86,8 +87,8 @@ but carries forward unmerged index entries.
        changes, reset is aborted.
 --
 
-If you want to undo a commit other than the latest on a branch,
-linkgit:git-revert[1] is your friend.
+See "Reset, restore and revert" in linkgit:git[1] for the differences
+between the three commands.
 
 
 OPTIONS
@@ -149,9 +150,9 @@ See also the `--amend` option to linkgit:git-commit[1].
 Undo a commit, making it a topic branch::
 +
 ------------
-$ git branch topic/wip     <1>
-$ git reset --hard HEAD~3  <2>
-$ git checkout topic/wip   <3>
+$ git branch topic/wip          <1>
+$ git reset --hard HEAD~3       <2>
+$ git switch topic/wip          <3>
 ------------
 +
 <1> You have made some commits, but realize they were premature
@@ -232,13 +233,13 @@ working tree are not in any shape to be committed yet, but you
 need to get to the other branch for a quick bugfix.
 +
 ------------
-$ git checkout feature ;# you were working in "feature" branch and
-$ work work work       ;# got interrupted
+$ git switch feature  ;# you were working in "feature" branch and
+$ work work work      ;# got interrupted
 $ git commit -a -m "snapshot WIP"                 <1>
-$ git checkout master
+$ git switch master
 $ fix fix fix
 $ git commit ;# commit with real log
-$ git checkout feature
+$ git switch feature
 $ git reset --soft HEAD^ ;# go back to WIP state  <2>
 $ git reset                                       <3>
 ------------
@@ -279,18 +280,18 @@ reset it while keeping the changes in your working tree.
 +
 ------------
 $ git tag start
-$ git checkout -b branch1
+$ git switch -c branch1
 $ edit
 $ git commit ...                            <1>
 $ edit
-$ git checkout -b branch2                   <2>
+$ git switch -c branch2                     <2>
 $ git reset --keep start                    <3>
 ------------
 +
 <1> This commits your first edits in `branch1`.
 <2> In the ideal world, you could have realized that the earlier
     commit did not belong to the new topic when you created and switched
-    to `branch2` (i.e. `git checkout -b branch2 start`), but nobody is
+    to `branch2` (i.e. `git switch -c branch2 start`), but nobody is
     perfect.
 <3> But you can use `reset --keep` to remove the unwanted commit after
     you switched to `branch2`.
diff --git a/Documentation/git-restore.txt b/Documentation/git-restore.txt
new file mode 100644 (file)
index 0000000..1ab2e40
--- /dev/null
@@ -0,0 +1,185 @@
+git-restore(1)
+==============
+
+NAME
+----
+git-restore - Restore working tree files
+
+SYNOPSIS
+--------
+[verse]
+'git restore' [<options>] [--source=<tree>] [--staged] [--worktree] <pathspec>...
+'git restore' (-p|--patch) [<options>] [--source=<tree>] [--staged] [--worktree] [<pathspec>...]
+
+DESCRIPTION
+-----------
+Restore specified paths in the working tree with some contents from a
+restore source. If a path is tracked but does not exist in the restore
+source, it will be removed to match the source.
+
+The command can also be used to restore the content in the index with
+`--staged`, or restore both the working tree and the index with
+`--staged --worktree`.
+
+By default, the restore sources for working tree and the index are the
+index and `HEAD` respectively. `--source` could be used to specify a
+commit as the restore source.
+
+See "Reset, restore and revert" in linkgit:git[1] for the differences
+between the three commands.
+
+THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
+
+OPTIONS
+-------
+-s <tree>::
+--source=<tree>::
+       Restore the working tree files with the content from the given
+       tree. It is common to specify the source tree by naming a
+       commit, branch or tag associated with it.
++
+If not specified, the default restore source for the working tree is
+the index, and the default restore source for the index is
+`HEAD`. When both `--staged` and `--worktree` are specified,
+`--source` must also be specified.
+
+-p::
+--patch::
+       Interactively select hunks in the difference between the
+       restore source and the restore location. See the ``Interactive
+       Mode'' section of linkgit:git-add[1] to learn how to operate
+       the `--patch` mode.
++
+Note that `--patch` can accept no pathspec and will prompt to restore
+all modified paths.
+
+-W::
+--worktree::
+-S::
+--staged::
+       Specify the restore location. If neither option is specified,
+       by default the working tree is restored. Specifying `--staged`
+       will only restore the index. Specifying both restores both.
+
+-q::
+--quiet::
+       Quiet, suppress feedback messages. Implies `--no-progress`.
+
+--progress::
+--no-progress::
+       Progress status is reported on the standard error stream
+       by default when it is attached to a terminal, unless `--quiet`
+       is specified. This flag enables progress reporting even if not
+       attached to a terminal, regardless of `--quiet`.
+
+--ours::
+--theirs::
+       When restoring files in the working tree from the index, use
+       stage #2 ('ours') or #3 ('theirs') for unmerged paths.
++
+Note that during `git rebase` and `git pull --rebase`, 'ours' and
+'theirs' may appear swapped. See the explanation of the same options
+in linkgit:git-checkout[1] for details.
+
+-m::
+--merge::
+       When restoring files on the working tree from the index,
+       recreate the conflicted merge in the unmerged paths.
+
+--conflict=<style>::
+       The same as `--merge` option above, but changes the way the
+       conflicting hunks are presented, overriding the
+       `merge.conflictStyle` configuration variable.  Possible values
+       are "merge" (default) and "diff3" (in addition to what is
+       shown by "merge" style, shows the original contents).
+
+--ignore-unmerged::
+       When restoring files on the working tree from the index, do
+       not abort the operation if there are unmerged entries and
+       neither `--ours`, `--theirs`, `--merge` or `--conflict` is
+       specified. Unmerged paths on the working tree are left alone.
+
+--ignore-skip-worktree-bits::
+       In sparse checkout mode, by default is to only update entries
+       matched by `<pathspec>` and sparse patterns in
+       $GIT_DIR/info/sparse-checkout. This option ignores the sparse
+       patterns and unconditionally restores any files in
+       `<pathspec>`.
+
+--overlay::
+--no-overlay::
+       In overlay mode, the command never removes files when
+       restoring. In no-overlay mode, tracked files that do not
+       appear in the `--source` tree are removed, to make them match
+       `<tree>` exactly. The default is no-overlay mode.
+
+EXAMPLES
+--------
+
+The following sequence switches to the `master` branch, reverts the
+`Makefile` to two revisions back, deletes hello.c by mistake, and gets
+it back from the index.
+
+------------
+$ git switch master
+$ git restore --source master~2 Makefile  <1>
+$ rm -f hello.c
+$ git restore hello.c                     <2>
+------------
+
+<1> take a file out of another commit
+<2> restore hello.c from the index
+
+If you want to restore _all_ C source files to match the version in
+the index, you can say
+
+------------
+$ git restore '*.c'
+------------
+
+Note the quotes around `*.c`.  The file `hello.c` will also be
+restored, even though it is no longer in the working tree, because the
+file globbing is used to match entries in the index (not in the
+working tree by the shell).
+
+To restore all files in the current directory
+
+------------
+$ git restore .
+------------
+
+or to restore all working tree files with 'top' pathspec magic (see
+linkgit:gitglossary[7])
+
+------------
+$ git restore :/
+------------
+
+To restore a file in the index to match the version in `HEAD` (this is
+the same as using linkgit:git-reset[1])
+
+------------
+$ git restore --staged hello.c
+------------
+
+or you can restore both the index and the working tree (this the same
+as using linkgit:git-checkout[1])
+
+------------
+$ git restore --source=HEAD --staged --worktree hello.c
+------------
+
+or the short form which is more practical but less readable:
+
+------------
+$ git restore -s@ -SW hello.c
+------------
+
+SEE ALSO
+--------
+linkgit:git-checkout[1],
+linkgit:git-reset[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
index 88609ff..9392760 100644 (file)
@@ -48,6 +48,7 @@ SYNOPSIS
             [ --date=<format>]
             [ [ --objects | --objects-edge | --objects-edge-aggressive ]
               [ --unpacked ]
+              [ --object-names | --no-object-names ]
               [ --filter=<filter-spec> [ --filter-print-omitted ] ] ]
             [ --missing=<missing-action> ]
             [ --pretty | --header ]
index 0c82ca5..9d22270 100644 (file)
@@ -9,9 +9,7 @@ SYNOPSIS
 --------
 [verse]
 'git revert' [--[no-]edit] [-n] [-m parent-number] [-s] [-S[<keyid>]] <commit>...
-'git revert' --continue
-'git revert' --quit
-'git revert' --abort
+'git revert' (--continue | --skip | --abort | --quit)
 
 DESCRIPTION
 -----------
@@ -26,10 +24,13 @@ effect of some earlier commits (often only a faulty one).  If you want to
 throw away all uncommitted changes in your working directory, you
 should see linkgit:git-reset[1], particularly the `--hard` option.  If
 you want to extract specific files as they were in another commit, you
-should see linkgit:git-checkout[1], specifically the `git checkout
-<commit> -- <filename>` syntax.  Take care with these alternatives as
+should see linkgit:git-restore[1], specifically the `--source`
+option. Take care with these alternatives as
 both will discard uncommitted changes in your working directory.
 
+See "Reset, restore and revert" in linkgit:git[1] for the differences
+between the three commands.
+
 OPTIONS
 -------
 <commit>...::
index e31ea7d..8fbe12c 100644 (file)
@@ -235,12 +235,12 @@ return to your original branch to make the emergency fix, like this:
 +
 ----------------------------------------------------------------
 # ... hack hack hack ...
-$ git checkout -b my_wip
+$ git switch -c my_wip
 $ git commit -a -m "WIP"
-$ git checkout master
+$ git switch master
 $ edit emergency fix
 $ git commit -a -m "Fix in a hurry"
-$ git checkout my_wip
+$ git switch my_wip
 $ git reset --soft HEAD^
 # ... continue hacking ...
 ----------------------------------------------------------------
@@ -293,7 +293,8 @@ SEE ALSO
 linkgit:git-checkout[1],
 linkgit:git-commit[1],
 linkgit:git-reflog[1],
-linkgit:git-reset[1]
+linkgit:git-reset[1],
+linkgit:git-switch[1]
 
 GIT
 ---
index 3071162..53774f5 100644 (file)
@@ -769,11 +769,11 @@ option for (hopefully) obvious reasons.
 +
 This option is NOT recommended as it makes it difficult to track down
 old references to SVN revision numbers in existing documentation, bug
-reports and archives.  If you plan to eventually migrate from SVN to Git
-and are certain about dropping SVN history, consider
-linkgit:git-filter-branch[1] instead.  filter-branch also allows
-reformatting of metadata for ease-of-reading and rewriting authorship
-info for non-"svn.authorsFile" users.
+reports, and archives.  If you plan to eventually migrate from SVN to
+Git and are certain about dropping SVN history, consider
+https://github.com/newren/git-filter-repo[git-filter-repo] instead.
+filter-repo also allows reformatting of metadata for ease-of-reading
+and rewriting authorship info for non-"svn.authorsFile" users.
 
 svn.useSvmProps::
 svn-remote.<name>.useSvmProps::
diff --git a/Documentation/git-switch.txt b/Documentation/git-switch.txt
new file mode 100644 (file)
index 0000000..1979003
--- /dev/null
@@ -0,0 +1,273 @@
+git-switch(1)
+=============
+
+NAME
+----
+git-switch - Switch branches
+
+SYNOPSIS
+--------
+[verse]
+'git switch' [<options>] [--no-guess] <branch>
+'git switch' [<options>] --detach [<start-point>]
+'git switch' [<options>] (-c|-C) <new-branch> [<start-point>]
+'git switch' [<options>] --orphan <new-branch>
+
+DESCRIPTION
+-----------
+Switch to a specified branch. The working tree and the index are
+updated to match the branch. All new commits will be added to the tip
+of this branch.
+
+Optionally a new branch could be created with either `-c`, `-C`,
+automatically from a remote branch of same name (see `--guess`), or
+detach the working tree from any branch with `--detach`, along with
+switching.
+
+Switching branches does not require a clean index and working tree
+(i.e. no differences compared to `HEAD`). The operation is aborted
+however if the operation leads to loss of local changes, unless told
+otherwise with `--discard-changes` or `--merge`.
+
+THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
+
+OPTIONS
+-------
+<branch>::
+       Branch to switch to.
+
+<new-branch>::
+       Name for the new branch.
+
+<start-point>::
+       The starting point for the new branch. Specifying a
+       `<start-point>` allows you to create a branch based on some
+       other point in history than where HEAD currently points. (Or,
+       in the case of `--detach`, allows you to inspect and detach
+       from some other point.)
++
+You can use the `@{-N}` syntax to refer to the N-th last
+branch/commit switched to using "git switch" or "git checkout"
+operation. You may also specify `-` which is synonymous to `@{-1}`.
+This is often used to switch quickly between two branches, or to undo
+a branch switch by mistake.
++
+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`.
+
+-c <new-branch>::
+--create <new-branch>::
+       Create a new branch named `<new-branch>` starting at
+       `<start-point>` before switching to the branch. This is a
+       convenient shortcut for:
++
+------------
+$ git branch <new-branch>
+$ git switch <new-branch>
+------------
+
+-C <new-branch>::
+--force-create <new-branch>::
+       Similar to `--create` except that if `<new-branch>` already
+       exists, it will be reset to `<start-point>`. This is a
+       convenient shortcut for:
++
+------------
+$ git branch -f <new-branch>
+$ git switch <new-branch>
+------------
+
+-d::
+--detach::
+       Switch to a commit for inspection and discardable
+       experiments. See the "DETACHED HEAD" section in
+       linkgit:git-checkout[1] for details.
+
+--guess::
+--no-guess::
+       If `<branch>` is not found but there does exist a tracking
+       branch in exactly one remote (call it `<remote>`) with a
+       matching name, treat as equivalent to
++
+------------
+$ git switch -c <branch> --track <remote>/<branch>
+------------
++
+If the branch exists in multiple remotes and one of them is named by
+the `checkout.defaultRemote` configuration variable, we'll use that
+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 linkgit:git-config[1].
++
+`--guess` is the default behavior. Use `--no-guess` to disable it.
+
+-f::
+--force::
+       An alias for `--discard-changes`.
+
+--discard-changes::
+       Proceed even if the index or the working tree differs from
+       `HEAD`. Both the index and working tree are restored to match
+       the switching target. If `--recurse-submodules` is specified,
+       submodule content is also restored to match the switching
+       target. This is used to throw away local changes.
+
+-m::
+--merge::
+       If you have local modifications to one or more files that are
+       different between the current branch and the branch to which
+       you are switching, the command refuses to switch branches in
+       order to preserve your modifications in context.  However,
+       with this option, a three-way merge between the current
+       branch, your working tree contents, and the new branch is
+       done, and you will be on the new branch.
++
+When a merge conflict happens, the index entries for conflicting
+paths are left unmerged, and you need to resolve the conflicts
+and mark the resolved paths with `git add` (or `git rm` if the merge
+should result in deletion of the path).
+
+--conflict=<style>::
+       The same as `--merge` option above, but changes the way the
+       conflicting hunks are presented, overriding the
+       `merge.conflictStyle` configuration variable.  Possible values are
+       "merge" (default) and "diff3" (in addition to what is shown by
+       "merge" style, shows the original contents).
+
+-q::
+--quiet::
+       Quiet, suppress feedback messages.
+
+--progress::
+--no-progress::
+       Progress status is reported on the standard error stream
+       by default when it is attached to a terminal, unless `--quiet`
+       is specified. This flag enables progress reporting even if not
+       attached to a terminal, regardless of `--quiet`.
+
+-t::
+--track::
+       When creating a new branch, set up "upstream" configuration.
+       `-c` is implied. See `--track` in linkgit:git-branch[1] for
+       details.
++
+If no `-c` option is given, the name of the new branch will be derived
+from the remote-tracking branch, by looking at the local part of the
+refspec configured for the corresponding remote, and then stripping
+the initial part up to the "*".  This would tell us to use `hack` as
+the local branch when branching off of `origin/hack` (or
+`remotes/origin/hack`, or even `refs/remotes/origin/hack`).  If the
+given name has no slash, or the above guessing results in an empty
+name, the guessing is aborted.  You can explicitly give a name with
+`-c` in such a case.
+
+--no-track::
+       Do not set up "upstream" configuration, even if the
+       `branch.autoSetupMerge` configuration variable is true.
+
+--orphan <new-branch>::
+       Create a new 'orphan' branch, named `<new-branch>`. All
+       tracked files are removed.
+
+--ignore-other-worktrees::
+       `git switch` refuses when the wanted ref is already
+       checked out by another worktree. This option makes it check
+       the ref out anyway. In other words, the ref can be held by
+       more than one worktree.
+
+--recurse-submodules::
+--no-recurse-submodules::
+       Using `--recurse-submodules` will update the content of all
+       initialized submodules according to the commit recorded in the
+       superproject. If nothing (or `--no-recurse-submodules`) is
+       used, the work trees of submodules will not be updated. Just
+       like linkgit:git-submodule[1], this will detach `HEAD` of the
+       submodules.
+
+EXAMPLES
+--------
+
+The following command switches to the "master" branch:
+
+------------
+$ git switch master
+------------
+
+After working in the wrong branch, switching to the correct branch
+would be done using:
+
+------------
+$ git switch mytopic
+------------
+
+However, your "wrong" branch and correct "mytopic" branch may differ
+in files that you have modified locally, in which case the above
+switch would fail like this:
+
+------------
+$ git switch mytopic
+error: You have local changes to 'frotz'; not switching branches.
+------------
+
+You can give the `-m` flag to the command, which would try a three-way
+merge:
+
+------------
+$ git switch -m mytopic
+Auto-merging frotz
+------------
+
+After this three-way merge, the local modifications are _not_
+registered in your index file, so `git diff` would show you what
+changes you made since the tip of the new branch.
+
+To switch back to the previous branch before we switched to mytopic
+(i.e. "master" branch):
+
+------------
+$ git switch -
+------------
+
+You can grow a new branch from any commit. For example, switch to
+"HEAD~3" and create branch "fixup":
+
+------------
+$ git switch -c fixup HEAD~3
+Switched to a new branch 'fixup'
+------------
+
+If you want to start a new branch from a remote branch of the same
+name:
+
+------------
+$ git switch new-topic
+Branch 'new-topic' set up to track remote branch 'new-topic' from 'origin'
+Switched to a new branch 'new-topic'
+------------
+
+To check out commit `HEAD~3` for temporary inspection or experiment
+without creating a new branch:
+
+------------
+$ git switch --detach HEAD~3
+HEAD is now at 9fc9555312 Merge branch 'cc/shared-index-permbits'
+------------
+
+If it turns out whatever you have done is worth keeping, you can
+always create a new name for it (without switching away):
+
+------------
+$ git switch -c good-surprises
+------------
+
+SEE ALSO
+--------
+linkgit:git-checkout[1],
+linkgit:git-branch[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
index a74e7b9..2e5599a 100644 (file)
@@ -64,6 +64,13 @@ OPTIONS
 -s::
 --sign::
        Make a GPG-signed tag, using the default e-mail address's key.
+       The default behavior of tag GPG-signing is controlled by `tag.gpgSign`
+       configuration variable if it exists, or disabled oder otherwise.
+       See linkgit:git-config[1].
+
+--no-sign::
+       Override `tag.gpgSign` configuration variable that is
+       set to force each and every tag to be signed.
 
 -u <keyid>::
 --local-user=<keyid>::
index f9b09db..9b82564 100644 (file)
@@ -57,7 +57,8 @@ help ...`.
        Run as if git was started in '<path>' instead of the current working
        directory.  When multiple `-C` options are given, each subsequent
        non-absolute `-C <path>` is interpreted relative to the preceding `-C
-       <path>`.
+       <path>`.  If '<path>' is present but empty, e.g. `-C ""`, then the
+       current working directory is left unchanged.
 +
 This option affects options that expect path name like `--git-dir` and
 `--work-tree` in that their interpretations of the path names would be
@@ -211,6 +212,26 @@ people via patch over e-mail.
 
 include::cmds-foreignscminterface.txt[]
 
+Reset, restore and revert
+~~~~~~~~~~~~~~~~~~~~~~~~~
+There are three commands with similar names: `git reset`,
+`git restore` and `git revert`.
+
+* linkgit:git-revert[1] is about making a new commit that reverts the
+  changes made by other commits.
+
+* linkgit:git-restore[1] is about restoring files in the working tree
+  from either the index or another commit. This command does not
+  update your branch. The command can also be used to restore files in
+  the index from another commit.
+
+* linkgit:git-reset[1] is about updating your branch, moving the tip
+  in order to add or remove commits from the branch. This operation
+  changes the commit history.
++
+`git reset` can also be used to restore the index, overlapping with
+`git restore`.
+
 
 Low-level commands (plumbing)
 -----------------------------
index 2796dfc..c5a528c 100644 (file)
@@ -112,7 +112,8 @@ Checking-out and checking-in
 
 These attributes affect how the contents stored in the
 repository are copied to the working tree files when commands
-such as 'git checkout' and 'git merge' run.  They also affect how
+such as 'git switch', 'git checkout'  and 'git merge' run.
+They also affect how
 Git stores the contents you prepare in the working tree in the
 repository upon 'git add' and 'git commit'.
 
@@ -809,6 +810,8 @@ patterns are available:
 
 - `css` suitable for cascading style sheets.
 
+- `dts` suitable for devicetree (DTS) files.
+
 - `fortran` suitable for source code in the Fortran language.
 
 - `fountain` suitable for Fountain documents.
index 592e06d..4b32876 100644 (file)
@@ -37,6 +37,12 @@ arguments.  Here are the rules:
    file called HEAD in your work tree, `git diff HEAD` is ambiguous, and
    you have to say either `git diff HEAD --` or `git diff -- HEAD` to
    disambiguate.
+
+ * Because `--` disambiguates revisions and paths in some commands, it
+   cannot be used for those commands to separate options and revisions.
+   You can use `--end-of-options` for this (it also works for commands
+   that do not distinguish between revisions in paths, in which case it
+   is simply an alias for `--`).
 +
 When writing a script that is expected to handle random user-input, it is
 a good practice to make it explicit which arguments are which by placing
@@ -47,8 +53,8 @@ disambiguating `--` at appropriate places.
    things:
 +
 --------------------------------
-$ git checkout -- *.c
-$ git checkout -- \*.c
+$ git restore *.c
+$ git restore \*.c
 --------------------------------
 +
 The former lets your shell expand the fileglob, and you are asking
@@ -209,6 +215,18 @@ See also http://marc.info/?l=git&m=116563135620359 and
 http://marc.info/?l=git&m=119150393620273 for further
 information.
 
+Some other commands that also work on files in the working tree and/or
+in the index can take `--staged` and/or `--worktree`.
+
+* `--staged` is exactly like `--cached`, which is used to ask a
+  command to only work on the index, not the working tree.
+
+* `--worktree` is the opposite, to ask a command to work on the
+  working tree only, not the index.
+
+* The two options can be specified together to ask a command to work
+  on both the index and the working tree.
+
 GIT
 ---
 Part of the linkgit:git[1] suite
index e29a9ef..f880d21 100644 (file)
@@ -741,7 +741,7 @@ used earlier, and create a branch in it. You do that by simply just
 saying that you want to check out a new branch:
 
 ------------
-$ git checkout -b mybranch
+$ git switch -c mybranch
 ------------
 
 will create a new branch based at the current `HEAD` position, and switch
@@ -755,7 +755,7 @@ just telling 'git checkout' what the base of the checkout would be.
 In other words, if you have an earlier tag or branch, you'd just do
 
 ------------
-$ git checkout -b mybranch earlier-commit
+$ git switch -c mybranch earlier-commit
 ------------
 
 and it would create the new branch `mybranch` at the earlier commit,
@@ -765,7 +765,7 @@ and check out the state at that time.
 You can always just jump back to your original `master` branch by doing
 
 ------------
-$ git checkout master
+$ git switch master
 ------------
 
 (or any other branch-name, for that matter) and if you forget which
@@ -794,7 +794,7 @@ $ git branch <branchname> [startingpoint]
 
 which will simply _create_ the branch, but will not do anything further.
 You can then later -- once you decide that you want to actually develop
-on that branch -- switch to that branch with a regular 'git checkout'
+on that branch -- switch to that branch with a regular 'git switch'
 with the branchname as the argument.
 
 
@@ -808,7 +808,7 @@ being the same as the original `master` branch, let's make sure we're in
 that branch, and do some work there.
 
 ------------------------------------------------
-$ git checkout mybranch
+$ git switch mybranch
 $ echo "Work, work, work" >>hello
 $ git commit -m "Some work." -i hello
 ------------------------------------------------
@@ -825,7 +825,7 @@ does some work in the original branch, and simulate that by going back
 to the master branch, and editing the same file differently there:
 
 ------------
-$ git checkout master
+$ git switch master
 ------------
 
 Here, take a moment to look at the contents of `hello`, and notice how they
@@ -958,7 +958,7 @@ to the `master` branch. Let's go back to `mybranch`, and run
 'git merge' to get the "upstream changes" back to your branch.
 
 ------------
-$ git checkout mybranch
+$ git switch mybranch
 $ git merge -m "Merge upstream changes." master
 ------------
 
@@ -1133,9 +1133,8 @@ Remember, before running 'git merge', our `master` head was at
 work." commit.
 
 ------------
-$ git checkout mybranch
-$ git reset --hard master^2
-$ git checkout master
+$ git switch -C mybranch master^2
+$ git switch master
 $ git reset --hard master^
 ------------
 
index 9f2528f..1bd919f 100644 (file)
@@ -41,7 +41,7 @@ following commands.
 
   * linkgit:git-log[1] to see what happened.
 
-  * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch
+  * linkgit:git-switch[1] and linkgit:git-branch[1] to switch
     branches.
 
   * linkgit:git-add[1] to manage the index file.
@@ -51,8 +51,7 @@ following commands.
 
   * linkgit:git-commit[1] to advance the current branch.
 
-  * linkgit:git-reset[1] and linkgit:git-checkout[1] (with
-    pathname parameters) to undo changes.
+  * linkgit:git-restore[1] to undo changes.
 
   * linkgit:git-merge[1] to merge between local branches.
 
@@ -80,9 +79,9 @@ $ git tag v2.43 <2>
 Create a topic branch and develop.::
 +
 ------------
-$ git checkout -b alsa-audio <1>
+$ git switch -c alsa-audio <1>
 $ edit/compile/test
-$ git checkout -- curses/ux_audio_oss.c <2>
+$ git restore curses/ux_audio_oss.c <2>
 $ git add curses/ux_audio_alsa.c <3>
 $ edit/compile/test
 $ git diff HEAD <4>
@@ -90,7 +89,7 @@ $ git commit -a -s <5>
 $ edit/compile/test
 $ git diff HEAD^ <6>
 $ git commit -a --amend <7>
-$ git checkout master <8>
+$ git switch master <8>
 $ git merge alsa-audio <9>
 $ git log --since='3 days ago' <10>
 $ git log v2.43.. curses/ <11>
@@ -148,11 +147,11 @@ Clone the upstream and work on it.  Feed changes to upstream.::
 ------------
 $ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
 $ cd my2.6
-$ git checkout -b mine master <1>
+$ git switch -c mine master <1>
 $ edit/compile/test; git commit -a -s <2>
 $ git format-patch master <3>
 $ git send-email --to="person <email@example.com>" 00*.patch <4>
-$ git checkout master <5>
+$ git switch master <5>
 $ git pull <6>
 $ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <7>
 $ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git <8>
@@ -194,7 +193,7 @@ satellite$ edit/compile/test/commit
 satellite$ git push origin <4>
 
 mothership$ cd frotz
-mothership$ git checkout master
+mothership$ git switch master
 mothership$ git merge satellite/master <5>
 ------------
 +
@@ -216,7 +215,7 @@ machine into the master branch.
 Branch off of a specific tag.::
 +
 ------------
-$ git checkout -b private2.6.14 v2.6.14 <1>
+$ git switch -c private2.6.14 v2.6.14 <1>
 $ edit/compile/test; git commit -a
 $ git checkout master
 $ git cherry-pick v2.6.14..private2.6.14 <2>
@@ -274,14 +273,14 @@ $ mailx <3>
 & s 2 3 4 5 ./+to-apply
 & s 7 8 ./+hold-linus
 & q
-$ git checkout -b topic/one master
+$ git switch -c topic/one master
 $ git am -3 -i -s ./+to-apply <4>
 $ compile/test
-$ git checkout -b hold/linus && git am -3 -i -s ./+hold-linus <5>
-$ git checkout topic/one && git rebase master <6>
-$ git checkout pu && git reset --hard next <7>
+$ git switch -c hold/linus && git am -3 -i -s ./+hold-linus <5>
+$ git switch topic/one && git rebase master <6>
+$ git switch -C pu next <7>
 $ git merge topic/one topic/two && git merge hold/linus <8>
-$ git checkout maint
+$ git switch maint
 $ git cherry-pick master~4 <9>
 $ compile/test
 $ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>
index 786e778..50365f2 100644 (file)
@@ -103,6 +103,28 @@ The default 'pre-commit' hook, when enabled--and with the
 `hooks.allownonascii` config option unset or set to false--prevents
 the use of non-ASCII filenames.
 
+pre-merge-commit
+~~~~~~~~~~~~~~~~
+
+This hook is invoked by linkgit:git-merge[1], and can be bypassed
+with the `--no-verify` option.  It takes no parameters, and is
+invoked after the merge has been carried out successfully and before
+obtaining the proposed commit log message to
+make a commit.  Exiting with a non-zero status from this script
+causes the `git merge` command to abort before creating a commit.
+
+The default 'pre-merge-commit' hook, when enabled, runs the
+'pre-commit' hook, if the latter is enabled.
+
+This hook is invoked with the environment variable
+`GIT_EDITOR=:` if the command will not bring up an editor
+to modify the commit message.
+
+If the merge cannot be carried out automatically, the conflicts
+need to be resolved and the result committed separately (see
+linkgit:git-merge[1]). At that point, this hook will not be executed,
+but the 'pre-commit' hook will, if it is enabled.
+
 prepare-commit-msg
 ~~~~~~~~~~~~~~~~~~
 
@@ -165,12 +187,13 @@ rebased, and is not set when rebasing the current branch.
 post-checkout
 ~~~~~~~~~~~~~
 
-This hook is invoked when a linkgit:git-checkout[1] is run after having updated the
+This hook is invoked when a linkgit:git-checkout[1] or
+linkgit:git-switch[1] is run after having updated the
 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 checkout`.
+This hook cannot affect the outcome of `git switch` or `git checkout`.
 
 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
@@ -406,7 +429,8 @@ exit with a zero status.
 For example, the hook can simply run `git read-tree -u -m HEAD "$1"`
 in order to emulate `git fetch` that is run in the reverse direction
 with `git push`, as the two-tree form of `git read-tree -u -m` is
-essentially the same as `git checkout` that switches branches while
+essentially the same as `git switch` or `git checkout`
+that switches branches while
 keeping the local changes in the working tree that do not interfere
 with the difference between the branches.
 
@@ -423,10 +447,12 @@ post-rewrite
 
 This hook is invoked by commands that rewrite commits
 (linkgit:git-commit[1] when called with `--amend` and
-linkgit:git-rebase[1]; currently `git filter-branch` does 'not' call
-it!).  Its first argument denotes the command it was invoked by:
-currently one of `amend` or `rebase`.  Further command-dependent
-arguments may be passed in the future.
+linkgit:git-rebase[1]; however, full-history (re)writing tools like
+linkgit:git-fast-import[1] or
+https://github.com/newren/git-filter-repo[git-filter-repo] typically
+do not call it!).  Its first argument denotes the command it was
+invoked by: currently one of `amend` or `rebase`.  Further
+command-dependent arguments may be passed in the future.
 
 The hook receives a list of the rewritten commits on stdin, in the
 format
index 43f80c8..a5c3c04 100644 (file)
@@ -297,9 +297,13 @@ Supported if the helper has the "option" capability.
        same batch are complete. Only objects which were reported
        in the output of 'list' with a sha1 may be fetched this way.
 +
-Optionally may output a 'lock <file>' line indicating a file under
-GIT_DIR/objects/pack which is keeping a pack until refs can be
-suitably updated.
+Optionally may output a 'lock <file>' line indicating the full path of
+a file under `$GIT_DIR/objects/pack` which is keeping a pack until
+refs can be suitably updated.  The path must end with `.keep`. This is
+a mechanism to name a <pack,idx,keep> tuple by giving only the keep
+component.  The kept pack will not be deleted by a concurrent repack,
+even though its objects may not be referenced until the fetch completes.
+The `.keep` file will be deleted at the conclusion of the fetch.
 +
 If option 'check-connectivity' is requested, the helper must output
 'connectivity-ok' if the clone is self-contained and connected.
index 216b11e..d6388f1 100644 (file)
@@ -59,7 +59,7 @@ objects/[0-9a-f][0-9a-f]::
        here are often called 'unpacked' (or 'loose') objects.
 
 objects/pack::
-       Packs (files that store many object in compressed form,
+       Packs (files that store many objects in compressed form,
        along with index files to allow them to be randomly
        accessed) are found in this directory.
 
index e0976f6..8bdb7d0 100644 (file)
@@ -370,13 +370,13 @@ situation:
 $ git status
 On branch master
 Changes to be committed:
-  (use "git reset HEAD <file>..." to unstage)
+  (use "git restore --staged <file>..." to unstage)
 
        new file:   closing.txt
 
 Changes not staged for commit:
   (use "git add <file>..." to update what will be committed)
-  (use "git checkout -- <file>..." to discard changes in working directory)
+  (use "git restore <file>..." to discard changes in working directory)
 
        modified:   file.txt
 
index 242de31..59ef5ce 100644 (file)
@@ -110,7 +110,7 @@ $ git status
 On branch master
 Changes to be committed:
 Your branch is up to date with 'origin/master'.
-  (use "git reset HEAD <file>..." to unstage)
+  (use "git restore --staged <file>..." to unstage)
 
        modified:   file1
        modified:   file2
@@ -207,7 +207,7 @@ automatically.  The asterisk marks the branch you are currently on;
 type
 
 ------------------------------------------------
-$ git checkout experimental
+$ git switch experimental
 ------------------------------------------------
 
 to switch to the experimental branch.  Now edit a file, commit the
@@ -216,7 +216,7 @@ change, and switch back to the master branch:
 ------------------------------------------------
 (edit file)
 $ git commit -a
-$ git checkout master
+$ git switch master
 ------------------------------------------------
 
 Check that the change you made is no longer visible, since it was
index c743609..3cc9b03 100644 (file)
@@ -28,8 +28,7 @@ Gitweb provides a web interface to Git repositories.  Its features include:
   revisions one at a time, viewing the history of the repository.
 * Finding commits which commit messages matches given search term.
 
-See http://git.kernel.org/?p=git/git.git;a=tree;f=gitweb[] or
-http://repo.or.cz/w/git.git/tree/HEAD:/gitweb/[] for gitweb source code,
+See http://repo.or.cz/w/git.git/tree/HEAD:/gitweb/[] for gitweb source code,
 browsed using gitweb itself.
 
 
index ca11c7b..abc0dc6 100644 (file)
@@ -301,8 +301,7 @@ topics on 'next':
 .Rewind and rebuild next
 [caption="Recipe: "]
 =====================================
-* `git checkout next`
-* `git reset --hard master`
+* `git switch -C next master`
 * `git merge ai/topic_in_next1`
 * `git merge ai/topic_in_next2`
 * ...
index 8d38ae6..090c888 100644 (file)
@@ -255,7 +255,7 @@ This commit is referred to as a "merge commit", or sometimes just a
 [[def_object]]object::
        The unit of storage in Git. It is uniquely identified by the
        <<def_SHA1,SHA-1>> of its contents. Consequently, an
-       object can not be changed.
+       object cannot be changed.
 
 [[def_object_database]]object database::
        Stores a set of "objects", and an individual <<def_object,object>> is
index 79a00d2..59b8ff1 100644 (file)
@@ -40,20 +40,24 @@ set to `no` at the beginning of them.
        case of a merge conflict.
 
 --ff::
-       When the merge resolves as a fast-forward, only update the branch
-       pointer, without creating a merge commit.  This is the default
-       behavior.
-
 --no-ff::
-       Create a merge commit even when the merge resolves as a
-       fast-forward.  This is the default behaviour when merging an
-       annotated (and possibly signed) tag that is not stored in
-       its natural place in 'refs/tags/' hierarchy.
-
 --ff-only::
-       Refuse to merge and exit with a non-zero status unless the
-       current `HEAD` is already up to date or the merge can be
-       resolved as a fast-forward.
+       Specifies how a merge is handled when the merged-in history is
+       already a descendant of the current history.  `--ff` is the
+       default unless merging an annotated (and possibly signed) tag
+       that is not stored in its natural place in the `refs/tags/`
+       hierarchy, in which case `--no-ff` is assumed.
++
+With `--ff`, when possible resolve the merge as a fast-forward (only
+update the branch pointer to match the merged branch; do not create a
+merge commit).  When not possible (when the merged-in history is not a
+descendant of the current history), create a merge commit.
++
+With `--no-ff`, create a merge commit in all cases, even when the merge
+could instead be resolved as a fast-forward.
++
+With `--ff-only`, resolve the merge as a fast-forward when possible.
+When not possible, refuse to merge and exit with a non-zero status.
 
 -S[<keyid>]::
 --gpg-sign[=<keyid>]::
@@ -105,6 +109,10 @@ option can be used to override --squash.
 +
 With --squash, --commit is not allowed, and will fail.
 
+--no-verify::
+       This option bypasses the pre-merge and commit-msg hooks.
+       See also linkgit:githooks[5].
+
 -s <strategy>::
 --strategy=<strategy>::
        Use the given merge strategy; can be supplied more than
index d1f080b..90ff9e2 100644 (file)
@@ -182,6 +182,14 @@ explicitly.
        Pretend as if all objects mentioned by reflogs are listed on the
        command line as `<commit>`.
 
+--alternate-refs::
+       Pretend as if all objects mentioned as ref tips of alternate
+       repositories were listed on the command line. An alternate
+       repository is any repository whose object directory is specified
+       in `objects/info/alternates`.  The set of included objects may
+       be modified by `core.alternateRefsCommand`, etc. See
+       linkgit:git-config[1].
+
 --single-worktree::
        By default, all working trees will be examined by the
        following options when there are more than one (see
@@ -708,6 +716,16 @@ ifdef::git-rev-list[]
        Only useful with `--objects`; print the object IDs that are not
        in packs.
 
+--object-names::
+       Only useful with `--objects`; print the names of the object IDs
+       that are found. This is the default behavior.
+
+--no-object-names::
+       Only useful with `--objects`; does not print the names of the object
+       IDs that are found. This inverts `--object-names`. This flag allows
+       the output to be more easily parsed by commands such as
+       linkgit:git-cat-file[1].
+
 --filter=<filter-spec>::
        Only useful with one of the `--objects*`; omits objects (usually
        blobs) from the list of printed objects.  The '<filter-spec>'
index 82c1e57..97f995e 100644 (file)
@@ -115,7 +115,7 @@ Here's an example to make it more clear:
 ------------------------------
 $ git config push.default current
 $ git config remote.pushdefault myfork
-$ git checkout -b mybranch origin/master
+$ git switch -c mybranch origin/master
 
 $ git rev-parse --symbolic-full-name @{upstream}
 refs/remotes/origin/master
index 5a57c4a..3bceb56 100644 (file)
@@ -3,6 +3,10 @@
        `.git/sequencer`.  Can be used to continue after resolving
        conflicts in a failed cherry-pick or revert.
 
+--skip::
+       Skip the current commit and continue with the rest of the
+       sequence.
+
 --quit::
        Forget about the current operation in progress.  Can be used
        to clear the sequencer state after a failed cherry-pick or
index 46c3d5c..ad9d019 100644 (file)
@@ -54,7 +54,7 @@ this:
 do not do this you will get an error for each ref that it does not point
 to a valid object.
 
-Note: As a side-effect of this you can not safely assume that all
+Note: As a side-effect of this you cannot safely assume that all
 objects you lookup are available in superproject. All submodule objects
 will be available the same way as the superprojects objects.
 
index 23c3cc7..71eb081 100644 (file)
@@ -35,7 +35,7 @@ Format details are given in a later section.
 === The Normal Format Target
 
 The normal format target is a tradition printf format and similar
-to GIT_TRACE format.  This format is enabled with the `GIT_TR`
+to GIT_TRACE format.  This format is enabled with the `GIT_TRACE2`
 environment variable or the `trace2.normalTarget` system or global
 config setting.
 
@@ -668,7 +668,7 @@ completed.)
        "event":"signal",
        ...
        "t_abs":0.001227,  # elapsed time in seconds
-       "signal":13        # SIGTERM, SIGINT, etc.
+       "signo":13         # SIGTERM, SIGINT, etc.
 }
 ------------
 
index bde1862..7962e32 100644 (file)
@@ -62,9 +62,7 @@ Initializing
 `setup_traverse_info`::
 
        Initialize a `traverse_info` given the pathname of the tree to start
-       traversing from. The `base` argument is assumed to be the `path`
-       member of the `name_entry` being recursed into unless the tree is a
-       top-level tree in which case the empty string ("") is used.
+       traversing from.
 
 Walking
 -------
@@ -140,6 +138,10 @@ same in the next callback invocation.
        This utilizes the memory structure of a tree entry to avoid the
        overhead of using a generic strlen().
 
+`strbuf_make_traverse_path`::
+
+       Convenience wrapper to `make_traverse_path` into a strbuf.
+
 Authors
 -------
 
index 16452a0..a4f1744 100644 (file)
@@ -44,8 +44,9 @@ HEADER:
 
   1-byte number (C) of "chunks"
 
-  1-byte (reserved for later use)
-     Current clients should ignore this value.
+  1-byte number (B) of base commit-graphs
+      We infer the length (H*B) of the Base Graphs chunk
+      from this value.
 
 CHUNK LOOKUP:
 
@@ -92,6 +93,12 @@ CHUNK DATA:
       positions for the parents until reaching a value with the most-significant
       bit on. The other bits correspond to the position of the last parent.
 
+  Base Graphs List (ID: {'B', 'A', 'S', 'E'}) [Optional]
+      This list of H-byte hashes describe a set of B commit-graph files that
+      form a commit-graph chain. The graph position for the ith commit in this
+      file's OID Lookup chunk is equal to i plus the number of commits in all
+      base graphs.  If B is non-zero, this chunk must exist.
+
 TRAILER:
 
        H-byte HASH-checksum of all of the above.
index 7805b09..729fbcb 100644 (file)
@@ -127,22 +127,196 @@ Design Details
   helpful for these clones, anyway. The commit-graph will not be read or
   written when shallow commits are present.
 
-Future Work
------------
-
-- After computing and storing generation numbers, we must make graph
-  walks aware of generation numbers to gain the performance benefits they
-  enable. This will mostly be accomplished by swapping a commit-date-ordered
-  priority queue with one ordered by generation number. The following
-  operations are important candidates:
-
-    - 'log --topo-order'
-    - 'tag --merged'
-
-- A server could provide a commit-graph file as part of the network protocol
-  to avoid extra calculations by clients. This feature is only of benefit if
-  the user is willing to trust the file, because verifying the file is correct
-  is as hard as computing it from scratch.
+Commit Graphs Chains
+--------------------
+
+Typically, repos grow with near-constant velocity (commits per day). Over time,
+the number of commits added by a fetch operation is much smaller than the
+number of commits in the full history. By creating a "chain" of commit-graphs,
+we enable fast writes of new commit data without rewriting the entire commit
+history -- at least, most of the time.
+
+## File Layout
+
+A commit-graph chain uses multiple files, and we use a fixed naming convention
+to organize these files. Each commit-graph file has a name
+`$OBJDIR/info/commit-graphs/graph-{hash}.graph` where `{hash}` is the hex-
+valued hash stored in the footer of that file (which is a hash of the file's
+contents before that hash). For a chain of commit-graph files, a plain-text
+file at `$OBJDIR/info/commit-graphs/commit-graph-chain` contains the
+hashes for the files in order from "lowest" to "highest".
+
+For example, if the `commit-graph-chain` file contains the lines
+
+```
+       {hash0}
+       {hash1}
+       {hash2}
+```
+
+then the commit-graph chain looks like the following diagram:
+
+ +-----------------------+
+ |  graph-{hash2}.graph  |
+ +-----------------------+
+         |
+ +-----------------------+
+ |                       |
+ |  graph-{hash1}.graph  |
+ |                       |
+ +-----------------------+
+         |
+ +-----------------------+
+ |                       |
+ |                       |
+ |                       |
+ |  graph-{hash0}.graph  |
+ |                       |
+ |                       |
+ |                       |
+ +-----------------------+
+
+Let X0 be the number of commits in `graph-{hash0}.graph`, X1 be the number of
+commits in `graph-{hash1}.graph`, and X2 be the number of commits in
+`graph-{hash2}.graph`. If a commit appears in position i in `graph-{hash2}.graph`,
+then we interpret this as being the commit in position (X0 + X1 + i), and that
+will be used as its "graph position". The commits in `graph-{hash2}.graph` use these
+positions to refer to their parents, which may be in `graph-{hash1}.graph` or
+`graph-{hash0}.graph`. We can navigate to an arbitrary commit in position j by checking
+its containment in the intervals [0, X0), [X0, X0 + X1), [X0 + X1, X0 + X1 +
+X2).
+
+Each commit-graph file (except the base, `graph-{hash0}.graph`) contains data
+specifying the hashes of all files in the lower layers. In the above example,
+`graph-{hash1}.graph` contains `{hash0}` while `graph-{hash2}.graph` contains
+`{hash0}` and `{hash1}`.
+
+## Merging commit-graph files
+
+If we only added a new commit-graph file on every write, we would run into a
+linear search problem through many commit-graph files.  Instead, we use a merge
+strategy to decide when the stack should collapse some number of levels.
+
+The diagram below shows such a collapse. As a set of new commits are added, it
+is determined by the merge strategy that the files should collapse to
+`graph-{hash1}`. Thus, the new commits, the commits in `graph-{hash2}` and
+the commits in `graph-{hash1}` should be combined into a new `graph-{hash3}`
+file.
+
+                           +---------------------+
+                           |                     |
+                           |    (new commits)    |
+                           |                     |
+                           +---------------------+
+                           |                     |
+ +-----------------------+  +---------------------+
+ |  graph-{hash2} |->|                     |
+ +-----------------------+  +---------------------+
+         |                 |                     |
+ +-----------------------+  +---------------------+
+ |                       |  |                     |
+ |  graph-{hash1} |->|                     |
+ |                       |  |                     |
+ +-----------------------+  +---------------------+
+         |                  tmp_graphXXX
+ +-----------------------+
+ |                       |
+ |                       |
+ |                       |
+ |  graph-{hash0} |
+ |                       |
+ |                       |
+ |                       |
+ +-----------------------+
+
+During this process, the commits to write are combined, sorted and we write the
+contents to a temporary file, all while holding a `commit-graph-chain.lock`
+lock-file.  When the file is flushed, we rename it to `graph-{hash3}`
+according to the computed `{hash3}`. Finally, we write the new chain data to
+`commit-graph-chain.lock`:
+
+```
+       {hash3}
+       {hash0}
+```
+
+We then close the lock-file.
+
+## Merge Strategy
+
+When writing a set of commits that do not exist in the commit-graph stack of
+height N, we default to creating a new file at level N + 1. We then decide to
+merge with the Nth level if one of two conditions hold:
+
+  1. `--size-multiple=<X>` is specified or X = 2, and the number of commits in
+     level N is less than X times the number of commits in level N + 1.
+
+  2. `--max-commits=<C>` is specified with non-zero C and the number of commits
+     in level N + 1 is more than C commits.
+
+This decision cascades down the levels: when we merge a level we create a new
+set of commits that then compares to the next level.
+
+The first condition bounds the number of levels to be logarithmic in the total
+number of commits.  The second condition bounds the total number of commits in
+a `graph-{hashN}` file and not in the `commit-graph` file, preventing
+significant performance issues when the stack merges and another process only
+partially reads the previous stack.
+
+The merge strategy values (2 for the size multiple, 64,000 for the maximum
+number of commits) could be extracted into config settings for full
+flexibility.
+
+## Deleting graph-{hash} files
+
+After a new tip file is written, some `graph-{hash}` files may no longer
+be part of a chain. It is important to remove these files from disk, eventually.
+The main reason to delay removal is that another process could read the
+`commit-graph-chain` file before it is rewritten, but then look for the
+`graph-{hash}` files after they are deleted.
+
+To allow holding old split commit-graphs for a while after they are unreferenced,
+we update the modified times of the files when they become unreferenced. Then,
+we scan the `$OBJDIR/info/commit-graphs/` directory for `graph-{hash}`
+files whose modified times are older than a given expiry window. This window
+defaults to zero, but can be changed using command-line arguments or a config
+setting.
+
+## Chains across multiple object directories
+
+In a repo with alternates, we look for the `commit-graph-chain` file starting
+in the local object directory and then in each alternate. The first file that
+exists defines our chain. As we look for the `graph-{hash}` files for
+each `{hash}` in the chain file, we follow the same pattern for the host
+directories.
+
+This allows commit-graphs to be split across multiple forks in a fork network.
+The typical case is a large "base" repo with many smaller forks.
+
+As the base repo advances, it will likely update and merge its commit-graph
+chain more frequently than the forks. If a fork updates their commit-graph after
+the base repo, then it should "reparent" the commit-graph chain onto the new
+chain in the base repo. When reading each `graph-{hash}` file, we track
+the object directory containing it. During a write of a new commit-graph file,
+we check for any changes in the source object directory and read the
+`commit-graph-chain` file for that source and create a new file based on those
+files. During this "reparent" operation, we necessarily need to collapse all
+levels in the fork, as all of the files are invalid against the new base file.
+
+It is crucial to be careful when cleaning up "unreferenced" `graph-{hash}.graph`
+files in this scenario. It falls to the user to define the proper settings for
+their custom environment:
+
+ 1. When merging levels in the base repo, the unreferenced files may still be
+    referenced by chains from fork repos.
+
+ 2. The expiry time should be set to a length of time such that every fork has
+    time to recompute their commit-graph chain to "reparent" onto the new base
+    file(s).
+
+ 3. If the commit-graph chain is updated in the base, the fork will not have
+    access to the new chain until its chain is updated to reference those files.
+    (This may change in the future [5].)
 
 Related Links
 -------------
@@ -170,3 +344,7 @@ Related Links
 
 [4] https://public-inbox.org/git/20180108154822.54829-1-git@jeffhostetler.com/T/#u
     A patch to remove the ahead-behind calculation from 'status'.
+
+[5] https://public-inbox.org/git/f27db281-abad-5043-6d71-cbb083b1c877@gmail.com/
+    A discussion of a "two-dimensional graph position" that can allow reading
+    multiple commit-graph chains at the same time.
index bc2ace2..2ae8fa4 100644 (file)
@@ -456,7 +456,7 @@ packfile marked as UNREACHABLE_GARBAGE (using the PSRC field; see
 below). To avoid the race when writing new objects referring to an
 about-to-be-deleted object, code paths that write new objects will
 need to copy any objects from UNREACHABLE_GARBAGE packs that they
-refer to to new, non-UNREACHABLE_GARBAGE packs (or loose objects).
+refer to new, non-UNREACHABLE_GARBAGE packs (or loose objects).
 UNREACHABLE_GARBAGE are then safe to delete if their creation time (as
 indicated by the file's mtime) is long enough ago.
 
index 896c7b3..210373e 100644 (file)
@@ -30,12 +30,20 @@ advance* during clone and fetch operations and thereby reduce download
 times and disk usage.  Missing objects can later be "demand fetched"
 if/when needed.
 
+A remote that can later provide the missing objects is called a
+promisor remote, as it promises to send the objects when
+requested. Initialy Git supported only one promisor remote, the origin
+remote from which the user cloned and that was configured in the
+"extensions.partialClone" config option. Later support for more than
+one promisor remote has been implemented.
+
 Use of partial clone requires that the user be online and the origin
-remote be available for on-demand fetching of missing objects.  This may
-or may not be problematic for the user.  For example, if the user can
-stay within the pre-selected subset of the source tree, they may not
-encounter any missing objects.  Alternatively, the user could try to
-pre-fetch various objects if they know that they are going offline.
+remote or other promisor remotes be available for on-demand fetching
+of missing objects.  This may or may not be problematic for the user.
+For example, if the user can stay within the pre-selected subset of
+the source tree, they may not encounter any missing objects.
+Alternatively, the user could try to pre-fetch various objects if they
+know that they are going offline.
 
 
 Non-Goals
@@ -100,18 +108,18 @@ or commits that reference missing trees.
 Handling Missing Objects
 ------------------------
 
-- An object may be missing due to a partial clone or fetch, or missing due
-  to repository corruption.  To differentiate these cases, the local
-  repository specially indicates such filtered packfiles obtained from the
-  promisor remote as "promisor packfiles".
+- An object may be missing due to a partial clone or fetch, or missing
+  due to repository corruption.  To differentiate these cases, the
+  local repository specially indicates such filtered packfiles
+  obtained from promisor remotes as "promisor packfiles".
 +
 These promisor packfiles consist of a "<name>.promisor" file with
 arbitrary contents (like the "<name>.keep" files), in addition to
 their "<name>.pack" and "<name>.idx" files.
 
 - The local repository considers a "promisor object" to be an object that
-  it knows (to the best of its ability) that the promisor remote has promised
-  that it has, either because the local repository has that object in one of
+  it knows (to the best of its ability) that promisor remotes have promised
+  that they have, either because the local repository has that object in one of
   its promisor packfiles, or because another promisor object refers to it.
 +
 When Git encounters a missing object, Git can see if it is a promisor object
@@ -123,12 +131,12 @@ expensive-to-modify list of missing objects.[a]
 - Since almost all Git code currently expects any referenced object to be
   present locally and because we do not want to force every command to do
   a dry-run first, a fallback mechanism is added to allow Git to attempt
-  to dynamically fetch missing objects from the promisor remote.
+  to dynamically fetch missing objects from promisor remotes.
 +
 When the normal object lookup fails to find an object, Git invokes
-fetch-object to try to get the object from the server and then retry
-the object lookup.  This allows objects to be "faulted in" without
-complicated prediction algorithms.
+promisor_remote_get_direct() to try to get the object from a promisor
+remote and then retry the object lookup.  This allows objects to be
+"faulted in" without complicated prediction algorithms.
 +
 For efficiency reasons, no check as to whether the missing object is
 actually a promisor object is performed.
@@ -157,8 +165,7 @@ and prefetch those objects in bulk.
 +
 We are not happy with this global variable and would like to remove it,
 but that requires significant refactoring of the object code to pass an
-additional flag.  We hope that concurrent efforts to add an ODB API can
-encompass this.
+additional flag.
 
 
 Fetching Missing Objects
@@ -182,21 +189,63 @@ has been updated to not use any object flags when the corresponding argument
   though they are not necessary.
 
 
+Using many promisor remotes
+---------------------------
+
+Many promisor remotes can be configured and used.
+
+This allows for example a user to have multiple geographically-close
+cache servers for fetching missing blobs while continuing to do
+filtered `git-fetch` commands from the central server.
+
+When fetching objects, promisor remotes are tried one after the other
+until all the objects have been fetched.
+
+Remotes that are considered "promisor" remotes are those specified by
+the following configuration variables:
+
+- `extensions.partialClone = <name>`
+
+- `remote.<name>.promisor = true`
+
+- `remote.<name>.partialCloneFilter = ...`
+
+Only one promisor remote can be configured using the
+`extensions.partialClone` config variable. This promisor remote will
+be the last one tried when fetching objects.
+
+We decided to make it the last one we try, because it is likely that
+someone using many promisor remotes is doing so because the other
+promisor remotes are better for some reason (maybe they are closer or
+faster for some kind of objects) than the origin, and the origin is
+likely to be the remote specified by extensions.partialClone.
+
+This justification is not very strong, but one choice had to be made,
+and anyway the long term plan should be to make the order somehow
+fully configurable.
+
+For now though the other promisor remotes will be tried in the order
+they appear in the config file.
+
 Current Limitations
 -------------------
 
-- The remote used for a partial clone (or the first partial fetch
-  following a regular clone) is marked as the "promisor remote".
+- It is not possible to specify the order in which the promisor
+  remotes are tried in other ways than the order in which they appear
+  in the config file.
 +
-We are currently limited to a single promisor remote and only that
-remote may be used for subsequent partial fetches.
+It is also not possible to specify an order to be used when fetching
+from one remote and a different order when fetching from another
+remote.
+
+- It is not possible to push only specific objects to a promisor
+  remote.
 +
-We accept this limitation because we believe initial users of this
-feature will be using it on repositories with a strong single central
-server.
+It is not possible to push at the same time to multiple promisor
+remote in a specific order.
 
-- Dynamic object fetching will only ask the promisor remote for missing
-  objects.  We assume that the promisor remote has a complete view of the
+- Dynamic object fetching will only ask promisor remotes for missing
+  objects.  We assume that promisor remotes have a complete view of the
   repository and can satisfy all such requests.
 
 - Repack essentially treats promisor and non-promisor packfiles as 2
@@ -218,15 +267,17 @@ server.
 Future Work
 -----------
 
-- Allow more than one promisor remote and define a strategy for fetching
-  missing objects from specific promisor remotes or of iterating over the
-  set of promisor remotes until a missing object is found.
+- Improve the way to specify the order in which promisor remotes are
+  tried.
 +
-A user might want to have multiple geographically-close cache servers
-for fetching missing blobs while continuing to do filtered `git-fetch`
-commands from the central server, for example.
+For example this could allow to specify explicitly something like:
+"When fetching from this remote, I want to use these promisor remotes
+in this order, though, when pushing or fetching to that remote, I want
+to use those promisor remotes in that order."
+
+- Allow pushing to promisor remotes.
 +
-Or the user might want to work in a triangular work flow with multiple
+The user might want to work in a triangular work flow with multiple
 promisor remotes that each have an incomplete view of the repository.
 
 - Allow repack to work on promisor packfiles (while keeping them distinct
index 03264c7..40f91f6 100644 (file)
@@ -141,7 +141,7 @@ Capabilities
 ------------
 
 There are two different types of capabilities: normal capabilities,
-which can be used to to convey information or alter the behavior of a
+which can be used to convey information or alter the behavior of a
 request, and commands, which are the core actions that a client wants to
 perform (fetch, push, etc).
 
index eff7890..8bce75b 100644 (file)
@@ -122,10 +122,10 @@ Tags are expected to always point at the same version of a project,
 while heads are expected to advance as development progresses.
 
 Create a new branch head pointing to one of these versions and check it
-out using linkgit:git-checkout[1]:
+out using linkgit:git-switch[1]:
 
 ------------------------------------------------
-$ git checkout -b new v2.6.13
+$ git switch -c new v2.6.13
 ------------------------------------------------
 
 The working directory then reflects the contents that the project had
@@ -282,10 +282,10 @@ a summary of the commands:
        this command will fail with a warning.
 `git branch -D <branch>`::
        delete the branch `<branch>` irrespective of its merged status.
-`git checkout <branch>`::
+`git switch <branch>`::
        make the current branch `<branch>`, updating the working
        directory to reflect the version referenced by `<branch>`.
-`git checkout -b <new> <start-point>`::
+`git switch -c <new> <start-point>`::
        create a new branch `<new>` referencing `<start-point>`, and
        check it out.
 
@@ -302,22 +302,22 @@ ref: refs/heads/master
 Examining an old version without creating a new branch
 ------------------------------------------------------
 
-The `git checkout` command normally expects a branch head, but will also
-accept an arbitrary commit; for example, you can check out the commit
-referenced by a tag:
+The `git switch` command normally expects a branch head, but will also
+accept an arbitrary commit when invoked with --detach; for example,
+you can check out the commit referenced by a tag:
 
 ------------------------------------------------
-$ git checkout v2.6.17
+$ git switch --detach v2.6.17
 Note: checking out 'v2.6.17'.
 
 You are in 'detached HEAD' state. You can look around, make experimental
 changes and commit them, and you can discard any commits you make in this
-state without impacting any branches by performing another checkout.
+state without impacting any branches by performing another switch.
 
 If you want to create a new branch to retain commits you create, you may
-do so (now or later) by using -b with the checkout command again. Example:
+do so (now or later) by using -c with the switch command again. Example:
 
-  git checkout -b new_branch_name
+  git switch -c new_branch_name
 
 HEAD is now at 427abfa Linux v2.6.17
 ------------------------------------------------
@@ -373,7 +373,7 @@ You might want to build on one of these remote-tracking branches
 on a branch of your own, just as you would for a tag:
 
 ------------------------------------------------
-$ git checkout -b my-todo-copy origin/todo
+$ git switch -c my-todo-copy origin/todo
 ------------------------------------------------
 
 You can also check out `origin/todo` directly to examine it or
@@ -1408,7 +1408,7 @@ If you get stuck and decide to just give up and throw the whole mess
 away, you can always return to the pre-merge state with
 
 -------------------------------------------------
-$ git reset --hard HEAD
+$ git merge --abort
 -------------------------------------------------
 
 Or, if you've already committed the merge that you want to throw away,
@@ -1446,7 +1446,7 @@ mistake, you can return the entire working tree to the last committed
 state with
 
 -------------------------------------------------
-$ git reset --hard HEAD
+$ git restore --staged --worktree :/
 -------------------------------------------------
 
 If you make a commit that you later wish you hadn't, there are two
@@ -1523,12 +1523,10 @@ Checking out an old version of a file
 
 In the process of undoing a previous bad change, you may find it
 useful to check out an older version of a particular file using
-linkgit:git-checkout[1].  We've used `git checkout` before to switch
-branches, but it has quite different behavior if it is given a path
-name: the command
+linkgit:git-restore[1]. The command
 
 -------------------------------------------------
-$ git checkout HEAD^ path/to/file
+$ git restore --source=HEAD^ path/to/file
 -------------------------------------------------
 
 replaces path/to/file by the contents it had in the commit HEAD^, and
@@ -2211,8 +2209,8 @@ $ git branch --track release origin/master
 These can be easily kept up to date using linkgit:git-pull[1].
 
 -------------------------------------------------
-$ git checkout test && git pull
-$ git checkout release && git pull
+$ git switch test && git pull
+$ git switch release && git pull
 -------------------------------------------------
 
 Important note!  If you have any local changes in these branches, then
@@ -2264,7 +2262,7 @@ tested changes
 2) help future bug hunters that use `git bisect` to find problems
 
 -------------------------------------------------
-$ git checkout -b speed-up-spinlocks v2.6.35
+$ git switch -c speed-up-spinlocks v2.6.35
 -------------------------------------------------
 
 Now you apply the patch(es), run some tests, and commit the change(s).  If
@@ -2279,7 +2277,7 @@ When you are happy with the state of this change, you can merge it into the
 "test" branch in preparation to make it public:
 
 -------------------------------------------------
-$ git checkout test && git merge speed-up-spinlocks
+$ git switch test && git merge speed-up-spinlocks
 -------------------------------------------------
 
 It is unlikely that you would have any conflicts here ... but you might if you
@@ -2291,7 +2289,7 @@ see the value of keeping each patch (or patch series) in its own branch.  It
 means that the patches can be moved into the `release` tree in