git/Documentation/gitcredentials.txt, branch v2.26.3

Merge branch 'bc/wildcard-credential'

2020-03-05T18:43:02Z

A configuration element used for credential subsystem can now use wildcard pattern to specify for which set of URLs the entry applies. * bc/wildcard-credential: credential: allow wildcard patterns when matching config credential: use the last matching username in the config t0300: add tests for some additional cases t1300: add test for urlmatch with multiple wildcards mailmap: add an additional email address for brian m. carlson

credential: allow wildcard patterns when matching config

2020-02-20T21:05:43Z

In some cases, a user will want to use a specific credential helper for a wildcard pattern, such as https://*.corp.example.com. We have code that handles this already with the urlmatch code, so let's use that instead of our custom code. Since the urlmatch code is a superset of our current matching in terms of capabilities, there shouldn't be any cases of things that matched previously that don't match now. However, in addition to wildcard matching, we now use partial path matching, which can cause slightly different behavior in the case that a helper applies to the prefix (considering path components) of the remote URL. While different, this is probably the behavior people were wanting anyway. Since we're using the urlmatch code, we need to encode the components we've gotten into a URL to match, so add a function to percent-encode data and format the URL with it. We now also no longer need to the custom code to match URLs, so let's remove it. Additionally, the urlmatch code always looks for the best match, whereas we want all matches for credential helpers to preserve existing behavior. Let's add an optional field, select_fn, that lets us control which items we want (in this case, all of them) and default it to the best-match code that already exists for other users. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

doc: move credential helper info into gitcredentials(7)

2020-02-14T22:43:16Z

The details of how credential helpers can be called or implemented were originally covered in Documentation/technical/. Those are topics that end users might care about (and we even referenced them in the credentials manpage), but those docs typically don't ship as part of the end user documentation, making them less useful. This situation got slightly worse recently in f3b9055624 (credential: move doc to credential.h, 2019-11-17), where we moved them into the C header file, making them even harder to find. So let's move put this information into the gitcredentials(7) documentation, which is meant to describe the overall concepts of our credential handling. This was already pointing to the API docs for these concepts, so we can just include it inline instead. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

credential: move doc to credential.h

2019-11-18T06:21:29Z

Move the documentation from Documentation/technical/api-credentials.txt to credential.h as it's easier for the developers to find the usage information beside the code instead of looking for it in another doc file. Documentation/technical/api-credentials.txt is removed because the information it has is now redundant and it'll be hard to keep it up to date and synchronized with the documentation in the header file. Documentation/git-credential.txt and Documentation/gitcredentials.txt now link to credential.h instead of Documentation/technical/api-credentials.txt for details about the credetials API. Signed-off-by: Heba Waly Signed-off-by: Junio C Hamano

doc: clarify gitcredentials path component matching

2018-09-27T22:24:50Z

The gitcredentials documentation implied that the config file's "pattern" URL might include a path component, but did not explain that it must match exactly (potentially leaving readers with the false hope that it would support a more flexible prefix match). Signed-off-by: David Zych Signed-off-by: Junio C Hamano

credential doc: make multiple-helper behavior more prominent

2017-05-02T01:58:06Z

Git's configuration system works by reading multiple configuration files in order, from general to specific: - first, the system configuration /etc/gitconfig - then the user's configuration (~/.gitconfig or ~/.config/git/config) - then the repository configuration (.git/config) For single-valued configuration items, the latest value wins. For multi-valued configuration items, values accumulate in that order. For example, this allows setting a credential helper globally in ~/.gitconfig that git will try to use in all repositories, regardless of whether they additionally provide another helper. This is usually a nice thing --- e.g. I can install helpers to use my OS keychain and to cache credentials for a short period of time globally. Sometimes people want to be able to override an inherited setting. For the credential.helper setting, this is done by setting the configuration item to empty before giving it a new value. This is already documented but the documentation is hard to find --- git-config(1) says to look at gitcredentials(7) and the config reference in gitcredentials(7) doesn't mention this issue. Move the documentation to the config reference to make it easier to find. Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

credential: let empty credential specs reset helper list

2016-02-26T18:58:14Z

Sine the credential.helper key is a multi-valued config list, there's no way to "unset" a helper once it's been set. So if your system /etc/gitconfig sets one, you can never avoid running it, but only add your own helpers on top. Since an empty value for credential.helper is nonsensical (it would just try to run "git-credential-"), we can assume nobody is using it. Let's define it to reset the helper list, letting you override lower-priority instances which have come before. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

*config.txt: stick to camelCase naming convention

2015-03-14T05:13:46Z

This should improve readability. Compare "thislongname" and "thisLongName". The following keys are left in unchanged. We can decide what to do with them later. - am.keepcr - core.autocrlf .safecrlf .trustctime - diff.dirstat .noprefix - gitcvs.usecrlfattr - gui.blamehistoryctx .trustmtime - pull.twohead - receive.autogc - sendemail.signedoffbycc .smtpsslcertpath .suppresscc Helped-by: Eric Sunshine Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

Documentation: the name of the system is 'Git', not 'git'

2013-02-01T21:53:33Z

Signed-off-by: Thomas Ackermann Signed-off-by: Junio C Hamano

docs: stop using asciidoc no-inline-literal

2012-04-26T20:19:06Z

In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: foo bar which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor ` used to erroneously auto-generate a mailto footnote for author@example.com - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential..\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano