git/Documentation/git-help.txt, branch v2.41.2

git docs: add a category for file formats, protocols and interfaces

2022-08-04T21:12:23Z

Create a new "File formats, protocols and other developer interfaces" section in the main "git help git" manual page and start moving the documentation that now lives in "Documentation/technical/*.git" over to it. This complements the newly added and adjacent "Repository, command and file interfaces" section. This makes the technical documentation more accessible and discoverable. Before this we wouldn't install it by default, and had no ability to build man page versions of them. The links to them from our existing documentation link to the generated HTML version of these docs. So let's start moving those over, starting with just the "bundle-format.txt" documentation added in 7378ec90e1c (doc: describe Git bundle format, 2020-02-07). We'll now have a new gitformat-bundle(5) man page. Subsequent commits will move more git internal format documentation over. Unfortunately the syntax of the current Documentation/technical/*.txt is not the same (when it comes to section headings etc.) as our Documentation/*.txt documentation, so change the relevant bits of syntax as we're moving this over. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

git docs: add a category for user-facing file, repo and command UX

2022-08-04T21:12:23Z

Create a new "Repository, command and file interfaces" section in the main "git help git" manual page. Move things that belong under this new criteria from the generic "Guides" section. The "Guides" section was added in f442f28a81b (git.txt: add list of guides, 2020-08-05). It makes sense to have e.g. "giteveryday(7)" and "gitfaq(7)" listed under "Guides". But placing e.g. "gitignore(5)" in it is stretching the meaning of what a "guide" is, ideally that section should list things similar to "giteveryday(7)" and "gitcore-tutorial(7)". An alternate name that was considered for this new section was "User formats", for consistency with the nomenclature used for man section 5 in general. My man(1) lists it as "File formats and conventions, e.g. /etc/passwd". So calling this "git help --formats" or "git help --user-formats" would make sense for e.g. gitignore(5), but would be stretching it somewhat for githooks(5), and would seem really suspect for the likes of gitcli(7). Let's instead pick a name that's closer to the generic term "User interface", which is really what this documentation discusses: General user-interface documentation that doesn't obviously belong elsewhere. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

git help doc: use "" instead of ""

2022-08-04T21:12:23Z

Replace the use of "" originally introduced (as "GUIDE") in a133737b809 (doc: include --guide option description for "git help", 2013-04-02) with the more generic "". The "" placeholder is more generic, and one we'll be able to use as we introduce new documentation categories. Let's also add "" to the "git help -h" output, when it was made to use parse_option() in in 41eb33bd0cb (help: use parseopt, 2008-02-24). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

help: add --no-[external-commands|aliases] for use with --all

2022-02-23T21:41:37Z

Add the ability to only emit git's own usage information under --all. This also allows us to extend the "test_section_spacing" tests added in a preceding commit to test "git help --all" output. Previously we could not do that, as the tests might find a git-* command in the "$PATH", which would make the output differ from one setup to another. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

help: correct usage & behavior of "git help --all"

2022-02-23T21:41:37Z

Do the same for the "--all" option that I did for "--guides" in 9856ea6785c (help: correct usage & behavior of "git help --guides", 2021-09-22). I.e. we've documented it as ignoring non-option arguments, let's have it error out instead. As with other changes made in 62f035aee3f (Merge branch 'ab/help-config-vars', 2021-10-13) this is technically a change in behavior, but in practice it's just a bug fix. We were ignoring this before, but by erroring we can simplify our documentation and synopsis, as well as avoid user confusion as they wonder what the difference between e.g. "git help --all" and "git help --all status" is (there wasn't any difference). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

help doc: add missing "]" to "[-a|--all]"

2022-02-23T21:41:36Z

Add a missing "]" to documentation added in 63eae83f8f3 (help: add "-a --verbose" to list all commands with synopsis, 2018-05-20). This made it seem as though "--[no-]verbose" can only be provided with "--all", not "-a". The corresponding usage information in the C code ("builtin_help_usage") does not have the same problem. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'ja/doc-cleanup'

2021-12-10T22:35:03Z

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 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

doc: express grammar placeholders between angle brackets

2021-11-09T17:39:11Z

This discerns user inputs from verbatim options in the synopsis. Signed-off-by: Jean-Noël Avila Signed-off-by: Junio C Hamano

help: correct logic error in combining --all and --config

2021-09-23T17:30:43Z

Fix a bug in the --config option that's been there ever since its introduction in 3ac68a93fd2 (help: add --config to list all available config, 2018-05-26). Die when --all and --config are combined, combining them doesn't make sense. The code for the --config option when combined with an earlier refactoring done to support the --guide option in 65f98358c0c (builtin/help.c: add --guide option, 2013-04-02) would cause us to take the "--all" branch early and ignore the --config option. Let's instead list these as incompatible, both in the synopsis and help output, and enforce it in the code itself. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

help: correct usage & behavior of "git help --guides"

2021-09-23T17:30:43Z

As noted in 65f98358c0c (builtin/help.c: add --guide option, 2013-04-02) and a133737b809 (doc: include --guide option description for "git help", 2013-04-02) which introduced the --guide option, it cannot be combined with e.g. . Change the command and the "SYNOPSIS" section to reflect that desired behavior. Now that we assert this in code we don't need to exhaustively describe the previous confusing behavior in the documentation either, instead of silently ignoring the provided argument we'll now error out. The "We're done. Ignore any remaining args" comment added in 15f7d494380 (builtin/help.c: split "-a" processing into two, 2013-04-02) can now be removed, it's obvious that we're asserting the behavior with the check of "argc". The "--config" option is still missing from the synopsis, it will be added in a subsequent commit where we'll fix bugs in its implementation. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano