summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2022-03-24Git 2.35.2Libravatar Johannes Schindelin1-0/+7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-24Sync with 2.34.2Libravatar Johannes Schindelin7-0/+80
* maint-2.34: Git 2.34.2 Git 2.33.2 Git 2.32.1 Git 2.31.2 GIT-VERSION-GEN: bump to v2.33.1 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user
2022-03-24Git 2.34.2Libravatar Johannes Schindelin1-0/+6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-24Sync with 2.33.2Libravatar Johannes Schindelin6-0/+74
* maint-2.33: Git 2.33.2 Git 2.32.1 Git 2.31.2 GIT-VERSION-GEN: bump to v2.33.1 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user
2022-03-24Git 2.33.2Libravatar Johannes Schindelin1-0/+15
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-24Sync with 2.32.1Libravatar Johannes Schindelin5-0/+59
* maint-2.32: Git 2.32.1 Git 2.31.2 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user
2022-03-24Git 2.32.1Libravatar Johannes Schindelin1-0/+6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-24Sync with 2.31.2Libravatar Johannes Schindelin4-0/+53
* maint-2.31: Git 2.31.2 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user
2022-03-24Git 2.31.2Libravatar Johannes Schindelin1-0/+6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-24Sync with 2.30.3Libravatar Johannes Schindelin3-0/+47
* maint-2.30: Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user
2022-03-24Git 2.30.3Libravatar Johannes Schindelin1-0/+24
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-21setup_git_directory(): add an owner check for the top-level directoryLibravatar Johannes Schindelin2-0/+23
It poses a security risk to search for a git directory outside of the directories owned by the current user. For example, it is common e.g. in computer pools of educational institutes to have a "scratch" space: a mounted disk with plenty of space that is regularly swiped where any authenticated user can create a directory to do their work. Merely navigating to such a space with a Git-enabled `PS1` when there is a maliciously-crafted `/scratch/.git/` can lead to a compromised account. The same holds true in multi-user setups running Windows, as `C:\` is writable to every authenticated user by default. To plug this vulnerability, we stop Git from accepting top-level directories owned by someone other than the current user. We avoid looking at the ownership of each and every directories between the current and the top-level one (if there are any between) to avoid introducing a performance bottleneck. This new default behavior is obviously incompatible with the concept of shared repositories, where we expect the top-level directory to be owned by only one of its legitimate users. To re-enable that use case, we add support for adding exceptions from the new default behavior via the config setting `safe.directory`. The `safe.directory` config setting is only respected in the system and global configs, not from repository configs or via the command-line, and can have multiple values to allow for multiple shared repositories. We are particularly careful to provide a helpful message to any user trying to use a shared repository. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-01-28Git 2.35.1Libravatar Junio C Hamano1-0/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-24Git 2.35Libravatar Junio C Hamano1-0/+10
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-20Merge branch 'js/branch-track-inherit'Libravatar Junio C Hamano2-7/+7
"git branch -h" incorrectly said "--track[=direct|inherit]", implying that "--trackinherit" is a valid option, which has been corrected. source: <3de40324bea6a1dd9bca2654721471e3809e87d8.1642538935.git.steadmon@google.com> source: <c3c26192-aee9-185a-e559-b8735139e49c@web.de> * js/branch-track-inherit: branch,checkout: fix --track documentation
2022-01-20branch,checkout: fix --track documentationLibravatar René Scharfe2-7/+7
Document that the accepted variants of the --track option are --track, --track=direct, and --track=inherit. The equal sign in the latter two cannot be replaced with whitespace; in general optional arguments need to be attached firmly to their option. Put "direct" consistently before "inherit", if only for the reasons that the former is the default, explained first in the documentation, and comes before the latter alphabetically. Mention both modes in the short help so that readers don't have to look them up in the full documentation. They are literal strings and thus untranslatable. PARSE_OPT_LITERAL_ARGHELP is inferred due to the pipe and parenthesis characters, so we don't have to provide that flag explicitly. Mention that -t has the same effect as --track and --track=direct. There is no way to specify inherit mode using the short option, because short options generally don't accept optional arguments. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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