[doc] Use man git to teach users how to navigate the docs

[jvns]

Here's a list of things I'm still considering in the hopes that it'll help with the discussion:

I'm not totally satisfied with the description of git help --user-interfaces here. It might be clearer to give examples of topics those guides cover, like "hooks, .gitignore, and more".

I thought about mentioning git help push and/or man git-push, but (from a Mastodon survey I did) git push --help is the one users are most familiar with, it's most similar to how other Unix tools work, and it makes the description really clear and concise (-h for short help, --help for long help).

We just added gitdatamodel here but I took it out because I couldn't find a place to put it in the new explanation that felt natural. I do think that discoverability of that guide is still an issue and it's something that's on my mind. One option in the future to make the guides more discoverable would be to feature them more often in Git's advice, for example see 'git help mergeconflicts' for a guide to handling merge conflicts. Users definitely do read the advice.

Related to the discussion here https://lore.kernel.org/git/7004c3b1-2100-4a90-9815-2a679ceb25b2@app.fastmail.com/T/#mf600063180d6239916e3fa6e9d33da86969547ec

ccing Kristoffer who edited this most recently.

cc: Kristoffer Haugsbakk kristofferhaugsbakk@fastmail.com
cc: Ben Knoble ben.knoble@gmail.com

[jvns]

/submit

[gitgitgadget]

Submitted as pull.2242.git.1790627574093.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-2242/jvns/update-git-v1

To fetch this version to local tag pr-2242/jvns/update-git-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-2242/jvns/update-git-v1

[gitgitgadget]

Ben Knoble wrote on the Git mailing list (how to reply to this email):

> Le 28 sept. 2026 à 16:33, Julia Evans via GitGitGadget <gitgitgadget@gmail.com> a écrit :
> 
> From: Julia Evans <julia@jvns.ca>
> 
> Many existing users of Git don't know how Git's documentation is
> structured, and a lot of folks have expressed frustration that `man git`
> doesn't make it easy to find out how to get help with using Git.
> 
> Explain how Git's help system works in `man git`
> (`git push -h` gives a short help, `git push --help` is the full docs),
> since it's a slightly unusual approach.

[snip]

> Mention `git help` instead of `giteveryday` for now, which does a better
> job of giving an overview of everyday commands.

[snip]

>    I thought about mentioning git help push and/or man git-push, but (from
>    a Mastodon survey I did) git push --help is the one users are most
>    familiar with, it's most similar to how other Unix tools work, and it
>    makes the description really clear and concise (-h for short help,
>    --help for long help).

I appreciate the concision. I think “git help cmd” is quite a bit more
useful than “git cmd --help” because the former supports
aliases, HTML formats, and various other documents.
I don’t know how to fit that in with what you already proposed,
though; I doubt that mentioning bare “git help” will push anyone towards
its manual to discover “git help cmd”, although the bottom of the help
output mentions it as a possibility. 

[Unrelated]
One thing I think Git is really missing is easy access to the stuff
in “git --html-path”. I have a custom script for that, but AFAICT even
“git help” in web mode can’t open all of it. 

[gitgitgadget]

User Ben Knoble <ben.knoble@gmail.com> has been added to the cc: list.

[gitgitgadget]

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

Ben Knoble <ben.knoble@gmail.com> writes:

>> Mention `git help` instead of `giteveryday` for now, which does a better
>> job of giving an overview of everyday commands.
>
> [snip]
>
>>    I thought about mentioning git help push and/or man git-push, but (from
>>    a Mastodon survey I did) git push --help is the one users are most
>>    familiar with, it's most similar to how other Unix tools work, and it
>>    makes the description really clear and concise (-h for short help,
>>    --help for long help).
> I appreciate the concision.

The survey result that says the users are more familiar with "git
cmd --help" merely tells us that they are not taking full advantage
of what they are offered ;-).

> I think “git help cmd” is quite a bit more
> useful than “git cmd --help” because the former supports
> aliases, HTML formats, and various other documents.

I agree that "git help cmd/concept/guide" is more useful for all
these reasons, with "git help help".

[gitgitgadget]

"Julia Evans" wrote on the Git mailing list (how to reply to this email):

> The survey result that says the users are more familiar with "git
> cmd --help" merely tells us that they are not taking full advantage
> of what they are offered ;-).

>> I think “git help cmd” is quite a bit more
>> useful than “git cmd --help” because the former supports
>> aliases, HTML formats, and various other documents.

Viewing the HTML docs with `git help` does seem very useful, especially for
folks who aren't as comfortable in the terminal. I had no idea you could do
that.

Perhaps we could mention `git help` like this:

> `git push --help` or `git help push` for the full documentation

and then advertise the superior features of `git help` like this
(in the last sentence of the DESCRIPTION).

> You can view an HTML version of the Git documentation at
> https://git-scm.com/docs, or on your computer with `git help`,
> for example `git help push --web`.

[gitgitgadget]

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

"Julia Evans" <julia@jvns.ca> writes:

> Perhaps we could mention `git help` like this:
>
>> `git push --help` or `git help push` for the full documentation
>
> and then advertise the superior features of `git help` like this
> (in the last sentence of the DESCRIPTION).

Amusingly

$ git help tutorial

begins with "man git-log" and "git help log".  The first one is so
old fashioned ;-)  Perhaps a more modern version should be given at
the very first part of the description section of

$ git help git

>> You can view an HTML version of the Git documentation at
>> https://git-scm.com/docs, or on your computer with `git help`,
>> for example `git help push --web`.

Please write it as "git help --web push".

The command line parser may be lenient at times, but we do not
guarantee it.  Please stick to published "git help cli" style in
your insturction materials.

[gitgitgadget]

"Julia Evans" wrote on the Git mailing list (how to reply to this email):

On Tue, Sep 29, 2026, at 3:51 PM, Junio C Hamano wrote:
> "Julia Evans" <julia@jvns.ca> writes:
>
>> Perhaps we could mention `git help` like this:
>>
>>> `git push --help` or `git help push` for the full documentation
>>
>> and then advertise the superior features of `git help` like this
>> (in the last sentence of the DESCRIPTION).
>
> Amusingly
>
> $ git help tutorial
>
> begins with "man git-log" and "git help log".  The first one is so
> old fashioned ;-) 

I still only use `man git-log` actually :)

> Perhaps a more modern version should be given at
> the very first part of the description section of
>
> $ git help git
> 

Will submit a v2 with the wording I suggested above
(since I think that's "a more modern version" of what
`git help tutorial` says)

>>> You can view an HTML version of the Git documentation at
>>> https://git-scm.com/docs, or on your computer with `git help`,
>>> for example `git help push --web`.
>
> Please write it as "git help --web push".

Will do.

> The command line parser may be lenient at times, but we do not
> guarantee it.  Please stick to published "git help cli" style in
> your insturction materials.

I tried to read `git help cli`, got extremely confused, and gave up so I'm
not sure what that style is but I'm always happy to be corrected if there's
a different preferred style :)

I do always test Git commands to make sure they work.

[gitgitgadget]

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

"Julia Evans" <julia@jvns.ca> writes:

> I tried to read `git help cli`, got extremely confused, and gave up so I'm
> not sure what that style is but I'm always happy to be corrected if there's
> a different preferred style :)

"Options come first and then args." appears very early.