summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2022-01-12Last minute fixes before -rc1Libravatar Junio C Hamano1-1/+10
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-10Git 2.35-rc0Libravatar Junio C Hamano1-0/+59
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-10Merge branch 'jc/doc-submitting-patches-choice-of-base'Libravatar Junio C Hamano1-14/+39
Extend the guidance to choose the base commit to build your work on, and hint/nudge contributors to read others' changes. * jc/doc-submitting-patches-choice-of-base: SubmittingPatchs: clarify choice of base and testing
2022-01-10Merge branch 'js/branch-track-inherit'Libravatar Junio C Hamano4-10/+21
"git -c branch.autosetupmerge=inherit branch new old" makes "new" to have the same upstream as the "old" branch, instead of marking "old" itself as its upstream. * js/branch-track-inherit: config: require lowercase for branch.*.autosetupmerge branch: add flags and config to inherit tracking branch: accept multiple upstream branches for tracking
2022-01-10Merge branch 'ds/fetch-pull-with-sparse-index'Libravatar Junio C Hamano1-0/+5
"git fetch" and "git pull" are now declared sparse-index clean. Also "git ls-files" learns the "--sparse" option to help debugging. * ds/fetch-pull-with-sparse-index: test-read-cache: remove --table, --expand options t1091/t3705: remove 'test-tool read-cache --table' t1092: replace 'read-cache --table' with 'ls-files --sparse' ls-files: add --sparse option fetch/pull: use the sparse index
2022-01-05The seventh batchLibravatar Junio C Hamano1-0/+49
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-05Merge branch 'gh/gpg-doc-markup-fix'Libravatar Junio C Hamano1-1/+1
Doc markup fix. * gh/gpg-doc-markup-fix: docs: add missing colon to Documentation/config/gpg.txt
2022-01-05Merge branch 'ds/repack-fixlets'Libravatar Junio C Hamano1-2/+3
Two fixes around "git repack". * ds/repack-fixlets: repack: make '--quiet' disable progress repack: respect kept objects with '--write-midx -b'
2022-01-05Merge branch 'jc/merge-detached-head-name'Libravatar Junio C Hamano2-2/+12
The default merge message prepared by "git merge" records the name of the current branch; the name can be overridden with a new option to allow users to pretend a merge is made on a different branch. * jc/merge-detached-head-name: merge: allow to pretend a merge is made into a different branch
2022-01-05Merge branch 'jk/ssh-signing-doc-markup-fix'Libravatar Junio C Hamano1-1/+1
Docfix. * jk/ssh-signing-doc-markup-fix: doc/config: mark ssh allowedSigners example as literal
2022-01-05Merge branch 'xw/am-empty'Libravatar Junio C Hamano2-2/+20
"git am" learns "--empty=(stop|drop|keep)" option to tweak what is done to a piece of e-mail without a patch in it. * xw/am-empty: am: support --allow-empty to record specific empty patches am: support --empty=<option> to handle empty patches doc: git-format-patch: describe the option --always
2022-01-03The sixth batchLibravatar Junio C Hamano1-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-03Merge branch 'en/sparse-checkout-set'Libravatar Junio C Hamano2-48/+60
The "init" and "set" subcommands in "git sparse-checkout" have been unified for a better user experience and performance. * en/sparse-checkout-set: sparse-checkout: remove stray trailing space clone: avoid using deprecated `sparse-checkout init` Documentation: clarify/correct a few sparsity related statements git-sparse-checkout.txt: update to document init/set/reapply changes sparse-checkout: enable reapply to take --[no-]{cone,sparse-index} sparse-checkout: enable `set` to initialize sparse-checkout mode sparse-checkout: split out code for tweaking settings config sparse-checkout: disallow --no-stdin as an argument to set sparse-checkout: add sanity-checks on initial sparsity state sparse-checkout: break apart functions for sparse_checkout_(set|add) sparse-checkout: pass use_stdin as a parameter instead of as a global
2021-12-30SubmittingPatchs: clarify choice of base and testingLibravatar Junio C Hamano1-14/+39
We encourage identifying what, among many topics on `next`, exact topics a new work depends on, instead of building directly on `next`. Let's clarify this in the documentation. Developers should know what they are building on top of, and be aware of which part of the system is currently being worked on. Encouraging them to make trial merges to `next` and `seen` themselves will incentivize them to read others' changes and understand them, eventually helping the developers to coordinate among themselves and reviewing each others' changes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-22The fifth batchLibravatar Junio C Hamano1-0/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-22Merge branch 'jz/apply-quiet-and-allow-empty'Libravatar Junio C Hamano1-1/+10
"git apply" has been taught to ignore a message without a patch with the "--allow-empty" option. It also learned to honor the "--quiet" option given from the command line. * jz/apply-quiet-and-allow-empty: git-apply: add --allow-empty flag git-apply: add --quiet flag
2021-12-22ls-files: add --sparse optionLibravatar Derrick Stolee1-0/+5
Existing callers to 'git ls-files' are expecting file names, not directories. It is best to expand a sparse index to show all of the contained files in this case. However, expert users may want to inspect the contents of the index itself including which directories are sparse. Add a --sparse option to allow users to request this information. During testing, I noticed that options such as --modified did not affect the output when the files in question were outside the sparse-checkout definition. Tests are added to document this preexisting behavior and how it remains unchanged with the sparse index and the --sparse option. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-21The fourth batchLibravatar Junio C Hamano1-1/+33
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-21Merge branch 'fs/ssh-signing-other-keytypes'Libravatar Junio C Hamano1-7/+10
The cryptographic signing using ssh keys can specify literal keys for keytypes whose name do not begin with the "ssh-" prefix by using the "key::" prefix mechanism (e.g. "key::ecdsa-sha2-nistp256"). * fs/ssh-signing-other-keytypes: ssh signing: make sign/amend test more resilient ssh signing: support non ssh-* keytypes
2021-12-21Merge branch 'fs/ssh-signing-key-lifetime'Libravatar Junio C Hamano1-0/+5
Extend the signing of objects with SSH keys and learn to pay attention to the key validity time range when verifying. * fs/ssh-signing-key-lifetime: ssh signing: verify ssh-keygen in test prereq ssh signing: make fmt-merge-msg consider key lifetime ssh signing: make verify-tag consider key lifetime ssh signing: make git log verify key lifetime ssh signing: make verify-commit consider key lifetime ssh signing: add key lifetime test prereqs ssh signing: use sigc struct to pass payload t/fmt-merge-msg: make gpgssh tests more specific t/fmt-merge-msg: do not redirect stderr
2021-12-21Merge branch 'jc/grep-patterntype-default-doc'Libravatar Junio C Hamano1-1/+2
Doc update. * jc/grep-patterntype-default-doc: grep: clarify what `grep.patternType=default` means
2021-12-20branch: add flags and config to inherit trackingLibravatar Josh Steadmon4-10/+21
It can be helpful when creating a new branch to use the existing tracking configuration from the branch point. However, there is currently not a method to automatically do so. Teach git-{branch,checkout,switch} an "inherit" argument to the "--track" option. When this is set, creating a new branch will cause the tracking configuration to default to the configuration of the branch point, if set. For example, if branch "main" tracks "origin/main", and we run `git checkout --track=inherit -b feature main`, then branch "feature" will track "origin/main". Thus, `git status` will show us how far ahead/behind we are from origin, and `git pull` will pull from origin. This is particularly useful when creating branches across many submodules, such as with `git submodule foreach ...` (or if running with a patch such as [1], which we use at $job), as it avoids having to manually set tracking info for each submodule. Since we've added an argument to "--track", also add "--track=direct" as another way to explicitly get the original "--track" behavior ("--track" without an argument still works as well). Finally, teach branch.autoSetupMerge a new "inherit" option. When this is set, "--track=inherit" becomes the default behavior. [1]: https://lore.kernel.org/git/20180927221603.148025-1-sbeller@google.com/ Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-20merge: allow to pretend a merge is made into a different branchLibravatar Junio C Hamano2-2/+12
When a series of patches for a topic-B depends on having topic-A, the workflow to prepare the topic-B branch would look like this: $ git checkout -b topic-B main $ git merge --no-ff --no-edit topic-A $ git am <mbox-for-topic-B When topic-A gets updated, recreating the first merge and rebasing the rest of the topic-B, all on detached HEAD, is a useful technique. After updating topic-A with its new round of patches: $ git checkout topic-B $ prev=$(git rev-parse 'HEAD^{/^Merge branch .topic-A. into}') $ git checkout --detach $prev^1 $ git merge --no-ff --no-edit topic-A $ git rebase --onto HEAD $prev @{-1}^0 $ git checkout -B @{-1} This will (0) check out the current topic-B. (1) find the previous merge of topic-A into topic-B. (2) detach the HEAD to the parent of the previous merge. (3) merge the updated topic-A to it. (4) reapply the patches to rebuild the rest of topic-B. (5) update topic-B with the result. without contaminating the reflog of topic-B too much. topic-B@{1} is the "logically previous" state before topic-A got updated, for example. At (4), comparison (e.g. range-diff) between HEAD and @{-1} is a meaningful way to sanity check the result, and the same can be done at (5) by comparing topic-B and topic-B@{1}. But there is one glitch. The merge into the detached HEAD done in the step (3) above gives us "Merge branch 'topic-A' into HEAD", and does not say "into topic-B". Teach the "--into-name=<branch>" option to "git merge" and its underlying "git fmt-merge-message", to pretend as if we were merging into <branch>, no matter what branch we are actually merging into, when they prepare the merge message. The pretend name honors the usual "into <target>" suppression mechanism, which can be seen in the tests added here. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-20repack: make '--quiet' disable progressLibravatar Derrick Stolee1-2/+3
While testing some ideas in 'git repack', I ran it with '--quiet' and discovered that some progress output was still shown. Specifically, the output for writing the multi-pack-index showed the progress. The 'show_progress' variable in cmd_repack() is initialized with isatty(2) and is not modified at all by the '--quiet' flag. The '--quiet' flag modifies the po_args.quiet option which is translated into a '--quiet' flag for the 'git pack-objects' child process. However, 'show_progress' is used to directly send progress information to the multi-pack-index writing logic which does not use a child process. The fix here is to modify 'show_progress' to be false if po_opts.quiet is true, and isatty(2) otherwise. This new expectation simplifies a later condition that checks both. Update the documentation to make it clear that '-q' will disable all progress in addition to ensuring the 'git pack-objects' child process will receive the flag. Use 'test_terminal' to check that this works to get around the isatty(2) check. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-17docs: add missing colon to Documentation/config/gpg.txtLibravatar Greg Hurrell1-1/+1
Add missing colon to ensure correct rendering of definition list item. Without the proper number of colons, it renders as just another top-level paragraph rather than a list item. Signed-off-by: Greg Hurrell <greg@hurrell.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-15am: support --allow-empty to record specific empty patchesLibravatar 徐沛文 (Aleen)1-1/+6
This option helps to record specific empty patches in the middle of an am session, which does create empty commits only when: 1. the index has not changed 2. lacking a branch When the index has changed, "--allow-empty" will create a non-empty commit like passing "--continue" or "--resolved". Signed-off-by: 徐沛文 (Aleen) <aleen42@vip.qq.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-15am: support --empty=<option> to handle empty patchesLibravatar 徐沛文 (Aleen)1-0/+9
Since that the command 'git-format-patch' can include patches of commits that emit no changes, the 'git-am' command should also support an option, named as '--empty', to specify how to handle those empty patches. In this commit, we have implemented three valid options ('stop', 'drop' and 'keep'). Signed-off-by: 徐沛文 (Aleen) <aleen42@vip.qq.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-15doc: git-format-patch: describe the option --alwaysLibravatar 徐沛文 (Aleen)1-1/+5
This commit has described how to use '--always' option in the command 'git-format-patch' to include patches for commits that emit no changes. Signed-off-by: 徐沛文 (Aleen) <aleen42@vip.qq.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-15doc/config: mark ssh allowedSigners example as literalLibravatar Jeff King1-1/+1
The discussion for gpg.ssh.allowedSignersFile shows an example string that contains "user1@example.com,user2@example.com". Asciidoc thinks these are real email addresses and generates "mailto" footnotes for them. This makes the rendered content more confusing, as it has extra "[1]" markers: The file consists of one or more lines of principals followed by an ssh public key. e.g.: user1@example.com[1],user2@example.com[2] ssh-rsa AAAAX1... See ssh-keygen(1) "ALLOWED SIGNERS" for details. and also generates pointless notes at the end of the page: NOTES 1. user1@example.com mailto:user1@example.com 2. user2@example.com mailto:user2@example.com We can fix this by putting the example into a backtick literal block. That inhibits the mailto generation, and as a bonus typesets the example text in a way that sets it off from the regular prose (a tt font for html, or bold in the roff manpage). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-15Documentation: clarify/correct a few sparsity related statementsLibravatar Elijah Newren2-5/+5
Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Reviewed-by: Victoria Dye <vdye@github.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-15git-sparse-checkout.txt: update to document init/set/reapply changesLibravatar Elijah Newren1-43/+55
As noted in the previous commit, using separate `init` and `set` steps with sparse-checkout result in a number of issues. The previous commits made `set` able to handle the work of both commands, and enabled reapply to tweak the {cone,sparse-index} settings. Update the documentation to reflect this, and mark `init` as deprecated. Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Reviewed-by: Victoria Dye <vdye@github.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-15The third batchLibravatar Junio C Hamano1-0/+65
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-15Merge branch 're/color-default-reset'Libravatar Junio C Hamano1-5/+18
"default" and "reset" colors have been added to our palette. * re/color-default-reset: color: allow colors to be prefixed with "reset" color: support "default" to restore fg/bg color color: add missing GIT_COLOR_* white/black constants
2021-12-15Merge branch 'es/doc-stdout-vs-stderr'Libravatar Junio C Hamano1-0/+27
Coding guideline document has been updated to clarify what goes to standard error in our system. * es/doc-stdout-vs-stderr: CodingGuidelines: document which output goes to stdout vs. stderr
2021-12-15Merge branch 'es/worktree-chatty-to-stderr'Libravatar Junio C Hamano1-1/+1
"git worktree add" showed "Preparing worktree" message to the standard output stream, but when it failed, the message from die() went to the standard error stream. Depending on the order the stdio streams are flushed at the program end, this resulted in confusing output. It has been corrected by sending all the chatty messages to the standard error stream. * es/worktree-chatty-to-stderr: git-worktree.txt: add missing `-v` to synopsis for `worktree list` worktree: send "chatty" messages to stderr
2021-12-15Merge branch 'es/pretty-describe-more'Libravatar Junio C Hamano1-5/+11
Extend "git log --format=%(describe)" placeholder to allow passing selected command-line options to the underlying "git describe" command. * es/pretty-describe-more: pretty: add abbrev option to %(describe) pretty: add tag option to %(describe) pretty.c: rework describe options parsing for better extensibility
2021-12-15Merge branch 'en/zdiff3'Libravatar Junio C Hamano8-20/+49
"Zealous diff3" style of merge conflict presentation has been added. * en/zdiff3: update documentation for new zdiff3 conflictStyle xdiff: implement a zealous diff3, or "zdiff3"
2021-12-13git-apply: add --allow-empty flagLibravatar Jerry Zhang1-1/+5
Some users or scripts will pipe "git diff" output to "git apply" when replaying diffs or commits. In these cases, they will rely on the return value of "git apply" to know whether the diff was applied successfully. However, for empty commits, "git apply" will fail. This complicates scripts since they have to either buffer the diff and check its length, or run diff again with "exit-code", essentially doing the diff twice. Add the "--allow-empty" flag to "git apply" which allows it to handle both empty diffs and empty commits created by "git format-patch --always" by doing nothing and returning 0. Add tests for both with and without --allow-empty. Signed-off-by: Jerry Zhang <jerry@skydio.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13git-apply: add --quiet flagLibravatar Jerry Zhang1-1/+6
Replace OPT_VERBOSE with OPT_VERBOSITY. This adds a --quiet flag to "git apply" so the user can turn down the verbosity. Signed-off-by: Jerry Zhang <jerry@skydio.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-10The second batchLibravatar Junio C Hamano1-0/+99
2021-12-10Merge branch 'jt/midx-doc-fix'Libravatar Junio C Hamano1-5/+0
Docfix. * jt/midx-doc-fix: Doc: no midx and partial clone relation
2021-12-10Merge branch 'tl/midx-docfix'Libravatar Junio C Hamano1-6/+6
Doc mark-up fix. * tl/midx-docfix: midx: fix a formatting issue in "multi-pack-index.txt"
2021-12-10Merge branch 'tw/var-default-branch'Libravatar Junio C Hamano1-0/+3
"git var GIT_DEFAULT_BRANCH" is a way to see what name is used for the newly created branch if "git init" is run. * tw/var-default-branch: var: add GIT_DEFAULT_BRANCH variable
2021-12-10Merge branch 'jk/strbuf-addftime-seconds-since-epoch'Libravatar Junio C Hamano1-1/+1
The "--date=format:<strftime>" gained a workaround for the lack of system support for a non-local timezone to handle "%s" placeholder. * jk/strbuf-addftime-seconds-since-epoch: strbuf_addftime(): handle "%s" manually
2021-12-10Merge branch 'jc/fix-first-object-walk'Libravatar Junio C Hamano1-5/+26
Doc update. * jc/fix-first-object-walk: docs: add headers in MyFirstObjectWalk docs: fix places that break compilation in MyFirstObjectWalk
2021-12-10Merge branch 'if/redact-packfile-uri'Libravatar Junio C Hamano1-2/+3
Redact the path part of packfile URI that appears in the trace output. * if/redact-packfile-uri: http-fetch: redact url on die() message fetch-pack: redact packfile urls in traces
2021-12-10Merge branch 'ja/doc-cleanup'Libravatar Junio C Hamano38-165/+167
Doc update. * ja/doc-cleanup: init doc: --shared=0xxx does not give umask but perm bits doc: git-init: clarify file modes in octal. doc: git-http-push: describe the refs as pattern pairs doc: uniformize <URL> placeholders' case doc: use three dots for indicating repetition instead of star doc: git-ls-files: express options as optional alternatives doc: use only hyphens as word separators in placeholders doc: express grammar placeholders between angle brackets doc: split placeholders as individual tokens doc: fix git credential synopsis
2021-12-10Merge branch 'cw/protocol-v2-doc-fix'Libravatar Junio C Hamano1-3/+3
Doc update. * cw/protocol-v2-doc-fix: protocol-v2.txt: align delim-pkt spec with usage
2021-12-09ssh signing: make verify-commit consider key lifetimeLibravatar Fabian Stelzer1-0/+5
If valid-before/after dates are configured for this signatures key in the allowedSigners file then the verification should check if the key was valid at the time the commit was made. This allows for graceful key rollover and revoking keys without invalidating all previous commits. This feature needs openssh > 8.8. Older ssh-keygen versions will simply ignore this flag and use the current time. Strictly speaking this feature is available in 8.7, but since 8.7 has a bug that makes it unusable in another needed call we require 8.8. Timestamp information is present on most invocations of check_signature. However signer ident is not. We will need the signer email / name to be able to implement "Trust on first use" functionality later. Since the payload contains all necessary information we can parse it from there. The caller only needs to provide us some info about the payload by setting payload_type in the signature_check struct. - Add payload_type field & enum and payload_timestamp to struct signature_check - Populate the timestamp when not already set if we know about the payload type - Pass -Overify-time={payload_timestamp} in the users timezone to all ssh-keygen verification calls - Set the payload type when verifying commits - Add tests for expired, not yet valid and keys having a commit date outside of key validity as well as within Signed-off-by: Fabian Stelzer <fs@gigacodes.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-05grep: clarify what `grep.patternType=default` meansLibravatar Junio C Hamano1-1/+2
We documented that with grep.patternType set to default, the "git grep" command returns to "the default matching behavior" in 84befcd0 (grep: add a grep.patternType configuration setting, 2012-08-03). The grep.extendedRegexp configuration variable was the only way to configure the behavior before that, after b22520a3 (grep: allow -E and -n to be turned on by default via configuration, 2011-03-30) introduced it. It is understandable that we referred to the behavior that honors the older configuration variable as "the default matching" behavior. It is fairly clear in its log message: When grep.patternType is set to a value other than "default", the grep.extendedRegexp setting is ignored. The value of "default" restores the current default behavior, including the grep.extendedRegexp behavior. But when the paragraph is read in isolation by a new person who is not aware of that backstory (which is the synonym for "most users"), the "default matching behavior" can be read as "how 'git grep' behaves without any configuration variables or options", which is "match the pattern as BRE". Clarify what the passage means by elaborating what the phrase "default matching behavior" wanted to mean. Helped-by: Johannes Altmanninger <aclopte@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>