# [PATCH] doc: clarify gitcredentials path component matching 2 messages from 2018-09-26 to 2018-09-27. Participants: Zych, David M, Jeff King. Thread: https://gitlist.dev/t/49434 ## Zych, David M, 2018-09-26 22:23 Subject: [PATCH] doc: clarify gitcredentials path component matching Message-ID: <1538000558-25523-1-git-send-email-dmrz@illinois.edu> URL: https://gitlist.dev/e/1538000558-25523-1-git-send-email-dmrz%40illinois.edu ``` 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 --- Documentation/gitcredentials.txt | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Documentation/gitcredentials.txt b/Documentation/gitcredentials.txt index f970196..adc7596 100644 --- a/Documentation/gitcredentials.txt +++ b/Documentation/gitcredentials.txt @@ -133,6 +133,12 @@ compares hostnames exactly, without considering whether two hosts are part of the same domain. Likewise, a config entry for `http://example.com` would not match: Git compares the protocols exactly. +If the "pattern" URL does include a path component, then this too must match +exactly: the context `https://example.com/bar/baz.git` will match a config +entry for `https://example.com/bar/baz.git` (in addition to matching the config +entry for `https://example.com`) but will not match a config entry for +`https://example.com/bar`. + CONFIGURATION OPTIONS --------------------- -- 2.7.4 ``` ## Jeff King, 2018-09-27 05:19 Subject: Re: [PATCH] doc: clarify gitcredentials path component matching Message-ID: <20180927051911.GA14178@sigill.intra.peff.net> URL: https://gitlist.dev/e/20180927051911.GA14178%40sigill.intra.peff.net In-Reply-To: <1538000558-25523-1-git-send-email-dmrz@illinois.edu> ``` On Wed, Sep 26, 2018 at 10:23:11PM +0000, Zych, David M wrote: > 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). > [...] Thanks, the proposed text looks perfect to me. -Peff ```