summaryrefslogtreecommitdiff
path: root/Documentation/config
AgeCommit message (Collapse)AuthorFilesLines
2022-03-09Merge branch 'en/present-despite-skipped'Libravatar Junio C Hamano1-0/+27
In sparse-checkouts, files mis-marked as missing from the working tree could lead to later problems. Such files were hard to discover, and harder to correct. Automatically detecting and correcting the marking of such files has been added to avoid these problems. * en/present-despite-skipped: repo_read_index: add config to expect files outside sparse patterns Accelerate clear_skip_worktree_from_present_files() by caching Update documentation related to sparsity and the skip-worktree bit repo_read_index: clear SKIP_WORKTREE bit from files present in worktree unpack-trees: fix accidental loss of user changes t1011: add testcase demonstrating accidental loss of user modifications
2022-03-06Merge branch 'ah/advice-switch-requires-detach-to-detach'Libravatar Junio C Hamano1-0/+3
The error message given by "git switch HEAD~4" has been clarified to suggest the "--detach" option that is required. * ah/advice-switch-requires-detach-to-detach: switch: mention the --detach option when dying due to lack of a branch
2022-03-01repo_read_index: add config to expect files outside sparse patternsLibravatar Elijah Newren1-0/+27
Typically with sparse checkouts, we expect files outside the sparsity patterns to be marked as SKIP_WORKTREE and be missing from the working tree. Sometimes this expectation would be violated however; including in cases such as: * users grabbing files from elsewhere and writing them to the worktree (perhaps by editing a cached copy in an editor, copying/renaming, or even untarring) * various git commands having incomplete or no support for the SKIP_WORKTREE bit[1,2] * users attempting to "abort" a sparse-checkout operation with a not-so-early Ctrl+C (updating $GIT_DIR/info/sparse-checkout and the working tree is not atomic)[3]. When the SKIP_WORKTREE bit in the index did not reflect the presence of the file in the working tree, it traditionally caused confusion and was difficult to detect and recover from. So, in a sparse checkout, since af6a51875a (repo_read_index: clear SKIP_WORKTREE bit from files present in worktree, 2022-01-14), Git automatically clears the SKIP_WORKTREE bit at index read time for entries corresponding to files that are present in the working tree. There is another workflow, however, where it is expected that paths outside the sparsity patterns appear to exist in the working tree and that they do not lose the SKIP_WORKTREE bit, at least until they get modified. A Git-aware virtual file system[4] takes advantage of its position as a file system driver to expose all files in the working tree, fetch them on demand using partial clone on access, and tell Git to pay attention to them on demand by updating the sparse checkout pattern on writes. This means that commands like "git status" only have to examine files that have potentially been modified, whereas commands like "ls" are able to show the entire codebase without requiring manual updates to the sparse checkout pattern. Thus since af6a51875a, Git with such Git-aware virtual file systems unsets the SKIP_WORKTREE bit for all files and commands like "git status" have to fetch and examine them all. Introduce a configuration setting sparse.expectFilesOutsideOfPatterns to allow limiting the tracked set of files to a small set once again. A Git-aware virtual file system or other application that wants to maintain files outside of the sparse checkout can set this in a repository to instruct Git not to check for the presence of SKIP_WORKTREE files. The setting defaults to false, so most users of sparse checkout will still get the benefit of an automatically updating index to recover from the variety of difficult issues detailed in af6a51875a for paths with SKIP_WORKTREE set despite the path being present. [1] https://lore.kernel.org/git/xmqqbmb1a7ga.fsf@gitster-ct.c.googlers.com/ [2] The three long paragraphs in the middle of https://lore.kernel.org/git/CABPp-BH9tju7WVm=QZDOvaMDdZbpNXrVWQdN-jmfN8wC6YVhmw@mail.gmail.com/ [3] https://lore.kernel.org/git/CABPp-BFnFpzwGC11TLoLs8YK5yiisA5D5-fFjXnJsbESVDwZsA@mail.gmail.com/ [4] such as the vfsd described in https://lore.kernel.org/git/20220207190320.2960362-1-jonathantanmy@google.com/ Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25switch: mention the --detach option when dying due to lack of a branchLibravatar Alex Henrie1-0/+3
Users who are accustomed to doing `git checkout <tag>` assume that `git switch <tag>` will do the same thing. Inform them of the --detach option so they aren't left wondering why `git switch` doesn't work but `git checkout` does. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25Merge branch 'js/apply-partial-clone-filters-recursively'Libravatar Junio C Hamano1-0/+5
"git clone --filter=... --recurse-submodules" only makes the top-level a partial clone, while submodules are fully cloned. This behaviour is changed to pass the same filter down to the submodules. * js/apply-partial-clone-filters-recursively: clone, submodule: pass partial clone filters to submodules
2022-02-25Merge branch 'ds/sparse-checkout-requires-per-worktree-config'Libravatar Junio C Hamano1-0/+31
"git sparse-checkout" wants to work with per-worktree configuration, but did not work well in a worktree attached to a bare repository. * ds/sparse-checkout-requires-per-worktree-config: config: make git_configset_get_string_tmp() private worktree: copy sparse-checkout patterns and config on add sparse-checkout: set worktree-config correctly config: add repo_config_set_worktree_gently() worktree: create init_worktree_config() Documentation: add extensions.worktreeConfig details
2022-02-18Merge branch 'gc/branch-recurse-submodules'Libravatar Junio C Hamano2-11/+29
"git branch" learned the "--recurse-submodules" option. * gc/branch-recurse-submodules: branch.c: use 'goto cleanup' in setup_tracking() to fix memory leaks branch: add --recurse-submodules option for branch creation builtin/branch: consolidate action-picking logic in cmd_branch() branch: add a dry_run parameter to create_branch() branch: make create_branch() always create a branch branch: move --set-upstream-to behavior to dwim_and_setup_tracking()
2022-02-16Merge branch 'js/no-more-legacy-stash'Libravatar Junio C Hamano1-7/+0
Removal of unused code and doc. * js/no-more-legacy-stash: stash: stop warning about the obsolete `stash.useBuiltin` config setting stash: remove documentation for `stash.useBuiltin` add: remove support for `git-legacy-stash` git-sh-setup: remove remnant bits referring to `git-legacy-stash`
2022-02-16Merge branch 'en/fetch-negotiation-default-fix'Libravatar Junio C Hamano1-12/+13
Interaction between fetch.negotiationAlgorithm and feature.experimental configuration variables has been corrected. * en/fetch-negotiation-default-fix: repo-settings: rename the traditional default fetch.negotiationAlgorithm repo-settings: fix error handling for unknown values repo-settings: fix checking for fetch.negotiationAlgorithm=default
2022-02-09clone, submodule: pass partial clone filters to submodulesLibravatar Josh Steadmon1-0/+5
When cloning a repo with a --filter and with --recurse-submodules enabled, the partial clone filter only applies to the top-level repo. This can lead to unexpected bandwidth and disk usage for projects which include large submodules. For example, a user might wish to make a partial clone of Gerrit and would run: `git clone --recurse-submodules --filter=blob:5k https://gerrit.googlesource.com/gerrit`. However, only the superproject would be a partial clone; all the submodules would have all blobs downloaded regardless of their size. With this change, the same filter can also be applied to submodules, meaning the expected bandwidth and disk savings apply consistently. To avoid changing default behavior, add a new clone flag, `--also-filter-submodules`. When this is set along with `--filter` and `--recurse-submodules`, the filter spec is passed along to git-submodule and git-submodule--helper, such that submodule clones also have the filter applied. This applies the same filter to the superproject and all submodules. Users who need to customize the filter per-submodule would need to clone with `--no-recurse-submodules` and then manually initialize each submodule with the proper filter. Applying filters to submodules should be safe thanks to Jonathan Tan's recent work [1, 2, 3] eliminating the use of alternates as a method of accessing submodule objects, so any submodule object access now triggers a lazy fetch from the submodule's promisor remote if the accessed object is missing. This patch is a reworked version of [4], which was created prior to Jonathan Tan's work. [1]: 8721e2e (Merge branch 'jt/partial-clone-submodule-1', 2021-07-16) [2]: 11e5d0a (Merge branch 'jt/grep-wo-submodule-odb-as-alternate', 2021-09-20) [3]: 162a13b (Merge branch 'jt/no-abuse-alternate-odb-for-submodules', 2021-10-25) [4]: https://lore.kernel.org/git/52bf9d45b8e2b72ff32aa773f2415bf7b2b86da2.1563322192.git.steadmon@google.com/ Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-08Documentation: add extensions.worktreeConfig detailsLibravatar Derrick Stolee1-0/+31
The extensions.worktreeConfig extension was added in 58b284a (worktree: add per-worktree config files, 2018-10-21) and was somewhat documented in Documentation/git-config.txt. However, the extensions.worktreeConfig value was not specified further in the list of possible config keys. The location of the config.worktree file is not specified, and there are some precautions that should be mentioned clearly, but are only mentioned in git-worktree.txt. Expand the documentation to help users discover the complexities of extensions.worktreeConfig by adding details and cross links in these locations (relative to Documentation/): - config/extensions.txt - git-config.txt - git-worktree.txt The updates focus on items such as * $GIT_DIR/config.worktree takes precedence over $GIT_COMMON_DIR/config. * The core.worktree and core.bare=true settings are incorrect to have in the common config file when extensions.worktreeConfig is enabled. * The sparse-checkout settings core.sparseCheckout[Cone] are recommended to be set in the worktree config. As documented in 11664196ac ("Revert "check_repository_format_gently(): refuse extensions for old repositories"", 2020-07-15), this extension must be considered regardless of the repository format version for historical reasons. A future change will update references to extensions.worktreeConfig within git-sparse-checkout.txt, but a behavior change is needed before making those updates. Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-04branch: add --recurse-submodules option for branch creationLibravatar Glen Choo2-11/+29
To improve the submodules UX, we would like to teach Git to handle branches in submodules. Start this process by teaching "git branch" the --recurse-submodules option so that "git branch --recurse-submodules topic" will create the `topic` branch in the superproject and its submodules. Although this commit does not introduce breaking changes, it does not work well with existing --recurse-submodules commands because "git branch --recurse-submodules" writes to the submodule ref store, but most commands only consider the superproject gitlink and ignore the submodule ref store. For example, "git checkout --recurse-submodules" will check out the commits in the superproject gitlinks (and put the submodules in detached HEAD) instead of checking out the submodule branches. Because of this, this commit introduces a new configuration value, `submodule.propagateBranches`. The plan is for Git commands to prioritize submodule ref store information over superproject gitlinks if this value is true. Because "git branch --recurse-submodules" writes to submodule ref stores, for the sake of clarity, it will not function unless this configuration value is set. This commit also includes changes that support working with submodules from a superproject commit because "branch --recurse-submodules" (and future commands) need to read .gitmodules and gitlinks from the superproject commit, but submodules are typically read from the filesystem's .gitmodules and the index's gitlinks. These changes are: * add a submodules_of_tree() helper that gives the relevant information of an in-tree submodule (e.g. path and oid) and initializes the repository * add is_tree_submodule_active() by adding a treeish_name parameter to is_submodule_active() * add the "submoduleNotUpdated" advice to advise users to update the submodules in their trees Incidentally, fix an incorrect usage string that combined the 'list' usage of git branch (-l) with the 'create' usage; this string has been incorrect since its inception, a8dfd5eac4 (Make builtin-branch.c use parse_options., 2007-10-07). Helped-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Glen Choo <chooglen@google.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-02repo-settings: rename the traditional default fetch.negotiationAlgorithmLibravatar Elijah Newren1-12/+13
Give the traditional default fetch.negotiationAlgorithm the name 'consecutive'. Also allow a choice of 'default' to have Git decide between the choices (currently, picking 'skipping' if feature.experimental is true and 'consecutive' otherwise). Update the documentation accordingly. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-31Merge branch 'js/branch-track-inherit' into gc/branch-recurse-submodulesLibravatar Junio C Hamano1-1/+2
* js/branch-track-inherit: branch,checkout: fix --track documentation branch,checkout: fix --track usage strings config: require lowercase for branch.*.autosetupmerge branch: add flags and config to inherit tracking branch: accept multiple upstream branches for tracking
2022-01-27stash: remove documentation for `stash.useBuiltin`Libravatar Johannes Schindelin1-7/+0
In 8a2cd3f5123 (stash: remove the stash.useBuiltin setting, 2020-03-03), we removed the setting, and for a couple of major versions, we still documented the setting, telling users that it is gone. We can now safely remove even the documentation. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-26Documentation/config/pgp.txt: add missing apostropheLibravatar Greg Hurrell1-1/+1
Add an apostrophe to "signatures" to indicate the possessive relationship in "the signature's creation". Signed-off-by: Greg Hurrell <greg@hurrell.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-26Documentation/config/pgp.txt: replace stray <TAB> character with <SPC>Libravatar Greg Hurrell1-1/+1
Specifically, replace the tab between "the" and "first" with a space. Signed-off-by: Greg Hurrell <greg@hurrell.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-10Merge branch 'js/branch-track-inherit'Libravatar Junio C Hamano1-1/+2
"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-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 '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
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 Steadmon1-1/+2
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-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-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-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>
2021-12-01update documentation for new zdiff3 conflictStyleLibravatar Elijah Newren1-1/+8
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-19ssh signing: support non ssh-* keytypesLibravatar Fabian Stelzer1-7/+10
The user.signingKey config for ssh signing supports either a path to a file containing the key or for the sake of convenience a literal string with the ssh public key. To differentiate between those two cases we check if the first few characters contain "ssh-" which is unlikely to be the start of a path. ssh supports other key types which are not prefixed with "ssh-" and will currently be treated as a file path and therefore fail to load. To remedy this we move the prefix check into its own function and introduce the prefix `key::` for literal ssh keys. This way we don't need to add new key types when they become available. The existing `ssh-` prefix is retained for compatibility with current user configs but removed from the official documentation to discourage its use. Signed-off-by: Fabian Stelzer <fs@gigacodes.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-01Merge branch 'hm/paint-hits-in-log-grep'Libravatar Junio C Hamano1-2/+5
"git log --grep=string --author=name" learns to highlight hits just like "git grep string" does. * hm/paint-hits-in-log-grep: grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 data pretty: colorize pattern matches in commit messages grep: refactor next_match() and match_one_pattern() for external use
2021-10-29Merge branch 'bs/doc-blame-color-lines'Libravatar Junio C Hamano1-2/+0
Doc fix. * bs/doc-blame-color-lines: git config doc: fix recent ASCIIDOC formatting regression
2021-10-25Merge branch 'fs/ssh-signing-fix'Libravatar Junio C Hamano1-3/+1
Fix-up for the other topic already in 'next'. * fs/ssh-signing-fix: gpg-interface: fix leak of strbufs in get_ssh_key_fingerprint() gpg-interface: fix leak of "line" in parse_ssh_output() ssh signing: clarify trustlevel usage in docs ssh signing: fmt-merge-msg tests & config parse
2021-10-25Merge branch 'fs/ssh-signing'Libravatar Junio C Hamano2-2/+50
Use ssh public crypto for object and push-cert signing. * fs/ssh-signing: ssh signing: test that gpg fails for unknown keys ssh signing: tests for logs, tags & push certs ssh signing: duplicate t7510 tests for commits ssh signing: verify signatures using ssh-keygen ssh signing: provide a textual signing_key_id ssh signing: retrieve a default key from ssh-agent ssh signing: add ssh key format and signing code ssh signing: add test prereqs ssh signing: preliminary refactoring and clean-up
2021-10-20git config doc: fix recent ASCIIDOC formatting regressionLibravatar Ævar Arnfjörð Bjarmason1-2/+0
Fix a regression in 8c328561332 (blame: document --color-* options, 2021-10-08), which added an extra newline before the "+" syntax. The "Documentation/doc-diff HEAD~ HEAD" output with this applied is: [...] @@ -1815,13 +1815,13 @@ CONFIGURATION FILE specified 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. 2.weeks.ago is valid to address anything older than 2 weeks. + Instead of an absolute timestamp relative timestamps work as well, + e.g. 2.weeks.ago is valid to address anything older than 2 weeks. - + It defaults to blue,12 month ago,white,1 month ago,red, which colors - everything older than one year blue, recent changes between one month - and one year old are kept white, and lines introduced within the last - month are colored red. + It defaults to blue,12 month ago,white,1 month ago,red, which + colors everything older than one year blue, recent changes between + one month and one year old are kept white, and lines introduced + within the last month are colored red. color.blame.repeatedLines Use the specified color to colorize line annotations for git blame Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-18Merge branch 'bs/doc-blame-color-lines'Libravatar Junio C Hamano1-15/+18
The "--color-lines" and "--color-by-age" options of "git blame" have been missing, which are now documented. * bs/doc-blame-color-lines: blame: document --color-* options blame: describe default output format
2021-10-18Merge branch 'js/retire-preserve-merges'Libravatar Junio C Hamano2-8/+0
The "--preserve-merges" option of "git rebase" has been removed. * js/retire-preserve-merges: sequencer: restrict scope of a formerly public function rebase: remove a no-longer-used function rebase: stop mentioning the -p option in comments rebase: remove obsolete code comment rebase: drop the internal `rebase--interactive` command git-svn: drop support for `--preserve-merges` rebase: drop support for `--preserve-merges` pull: remove support for `--rebase=preserve` tests: stop testing `git rebase --preserve-merges` remote: warn about unhandled branch.<name>.rebase values t5520: do not use `pull.rebase=preserve`
2021-10-13ssh signing: clarify trustlevel usage in docsLibravatar Fabian Stelzer1-3/+1
facca53ac added verification for ssh signatures but incorrectly described the usage of gpg.minTrustLevel. While the verifications trustlevel is stil set to fully or undefined depending on if the key is known or not it has no effect on the verification result. Unknown keys will always fail verification. This commit updates the docs to match this behaviour. Signed-off-by: Fabian Stelzer <fs@gigacodes.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12Merge branch 'fs/ssh-signing' into fs/ssh-signing-fixLibravatar Junio C Hamano2-2/+50
* fs/ssh-signing: ssh signing: test that gpg fails for unknown keys ssh signing: tests for logs, tags & push certs ssh signing: duplicate t7510 tests for commits ssh signing: verify signatures using ssh-keygen ssh signing: provide a textual signing_key_id ssh signing: retrieve a default key from ssh-agent ssh signing: add ssh key format and signing code ssh signing: add test prereqs ssh signing: preliminary refactoring and clean-up
2021-10-11Merge branch 'tb/midx-write-propagate-namehash'Libravatar Junio C Hamano1-0/+4
"git multi-pack-index write --bitmap" learns to propagate the hashcache from original bitmap to resulting bitmap. * tb/midx-write-propagate-namehash: t5326: test propagating hashcache values p5326: generate pack bitmaps before writing the MIDX bitmap p5326: don't set core.multiPackIndex unnecessarily p5326: create missing 'perf-tag' tag midx.c: respect 'pack.writeBitmapHashcache' when writing bitmaps pack-bitmap.c: propagate namehash values from existing bitmaps t/helper/test-bitmap.c: add 'dump-hashes' mode
2021-10-08pretty: colorize pattern matches in commit messagesLibravatar Hamza Mahfooz1-2/+5
The "git log" command limits its output to the commits that contain strings matched by a pattern when the "--grep=<pattern>" option is used, but unlike output from "git grep -e <pattern>", the matches are not highlighted, making them harder to spot. Teach the pretty-printer code to highlight matches from the "--grep=<pattern>", "--author=<pattern>" and "--committer=<pattern>" options (to view the last one, you may have to ask for --pretty=fuller). Also, it must be noted that we are effectively greping the content twice (because it would be a hassle to rework the existing matching code to do a /g match and then pass it all down to the coloring code), however it only slows down "git log --author=^H" on this repository by around 1-2% (compared to v2.33.0), so it should be a small enough slow down to justify the addition of the feature. Signed-off-by: Hamza Mahfooz <someguy@effective-light.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08blame: document --color-* optionsLibravatar Bagas Sanjaya1-15/+18
Commit cdc2d5f11f1a (builtin/blame: dim uninteresting metadata lines, 2018-04-23) and 25d5f52901f0 (builtin/blame: highlight recently changed lines, 2018-04-23) introduce --color-lines and --color-by-age options to git blame, respectively. While both options are mentioned in usage help, they aren't documented in git-blame(1). Document them. Co-authored-by: Dr. Matthias St. Pierre <m.st.pierre@ncp-e.com> Signed-off-by: Dr. Matthias St. Pierre <m.st.pierre@ncp-e.com> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-14midx.c: respect 'pack.writeBitmapHashcache' when writing bitmapsLibravatar Taylor Blau1-0/+4
In the previous commit, the bitmap writing code learned to propagate values from an existing hash-cache extension into the bitmap that it is writing. Now that that functionality exists, let's expose it by teaching the 'git multi-pack-index' builtin to respect the `pack.writeBitmapHashCache` option so that the hash-cache may be written at all. Two minor points worth noting here: - The 'git multi-pack-index write' sub-command didn't previously read any configuration (instead this is handled in the base command). A separate handler is added here to respect this write-specific config option. - I briefly considered adding a 'bitmap_flags' field to the static options struct, but decided against it since it would require plumbing through a new parameter to the write_midx_file() function. Instead, a new MIDX-specific flag is added, which is translated to the corresponding bitmap one. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-10ssh signing: verify signatures using ssh-keygenLibravatar Fabian Stelzer1-0/+35
To verify a ssh signature we first call ssh-keygen -Y find-principal to look up the signing principal by their public key from the allowedSignersFile. If the key is found then we do a verify. Otherwise we only validate the signature but can not verify the signers identity. Verification uses the gpg.ssh.allowedSignersFile (see ssh-keygen(1) "ALLOWED SIGNERS") which contains valid public keys and a principal (usually user@domain). Depending on the environment this file can be managed by the individual developer or for example generated by the central repository server from known ssh keys with push access. This file is usually stored outside the repository, but if the repository only allows signed commits/pushes, the user might choose to store it in the repository. To revoke a key put the public key without the principal prefix into gpg.ssh.revocationKeyring or generate a KRL (see ssh-keygen(1) "KEY REVOCATION LISTS"). The same considerations about who to trust for verification as with the allowedSignersFile apply. Using SSH CA Keys with these files is also possible. Add "cert-authority" as key option between the principal and the key to mark it as a CA and all keys signed by it as valid for this CA. See "CERTIFICATES" in ssh-keygen(1). Signed-off-by: Fabian Stelzer <fs@gigacodes.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-10ssh signing: retrieve a default key from ssh-agentLibravatar Fabian Stelzer2-1/+9
If user.signingkey is not set and a ssh signature is requested we call gpg.ssh.defaultKeyCommand (typically "ssh-add -L") and use the first key we get Signed-off-by: Fabian Stelzer <fs@gigacodes.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-10ssh signing: add ssh key format and signing codeLibravatar Fabian Stelzer2-2/+7
Implements the actual sign_buffer_ssh operation and move some shared cleanup code into a strbuf function Set gpg.format = ssh and user.signingkey to either a ssh public key string (like from an authorized_keys file), or a ssh key file. If the key file or the config value itself contains only a public key then the private key needs to be available via ssh-agent. gpg.ssh.program can be set to an alternative location of ssh-keygen. A somewhat recent openssh version (8.2p1+) of ssh-keygen is needed for this feature. Since only ssh-keygen is needed it can this way be installed seperately without upgrading your system openssh packages. Signed-off-by: Fabian Stelzer <fs@gigacodes.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-10Merge branch 'ab/help-autocorrect-prompt'Libravatar Junio C Hamano1-7/+9
The logic for auto-correction of misspelt subcommands learned to go interactive when the help.autocorrect configuration variable is set to 'prompt'. * ab/help-autocorrect-prompt: help.c: help.autocorrect=prompt waits for user action
2021-09-10Merge branch 'jk/log-warn-on-bogus-encoding'Libravatar Junio C Hamano1-1/+1
Doc update plus improved error reporting. * jk/log-warn-on-bogus-encoding: docs: use "character encoding" to refer to commit-object encoding logmsg_reencode(): warn when iconv() fails
2021-09-10Merge branch 'ka/want-ref-in-namespace'Libravatar Junio C Hamano1-5/+9
"git upload-pack" which runs on the other side of "git fetch" forgot to take the ref namespaces into account when handling want-ref requests. * ka/want-ref-in-namespace: docs: clarify the interaction of transfer.hideRefs and namespaces upload-pack.c: treat want-ref relative to namespace t5730: introduce fetch command helper
2021-09-07pull: remove support for `--rebase=preserve`Libravatar Johannes Schindelin2-8/+0
In preparation for `git-rebase--preserve-merges.sh` entering its after life, we remove this (deprecated) option that would still rely on it. To help users transition who still did not receive the memo about the deprecation, we offer a helpful error message instead of throwing our hands in the air and saying that we don't know that option, never heard of it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>