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.

Remove the references to gittutorial and giteveryday since they're unlikely to help new users learn Git. Currently they feel very aspirational (it would be nice to have a tutorial and a guide to everyday Git commands!), but we should give users a realistic view of what the documentation actually provides.

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

Also mention `git help --guides` and `git help --user-interfaces`, since those parts of the documentation are useful and hard to discover.

Do not mention `git help --developer-interfaces` since it's not relevant to users.

Signed-off-by: Julia Evans <julia@jvns.ca>
---
    [doc] Use man git to teach users how to navigate the docs
    
    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.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2242%2Fjvns%2Fupdate-git-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2242/jvns/update-git-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2242

 Documentation/git.adoc | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

[snip]

[snip]

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.

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

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 agree that "git help cmd/concept/guide" is more useful for all these reasons, with "git help help".

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:

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

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

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

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.

On Tue, Sep 29, 2026, at 3:51 PM, Junio C Hamano wrote:

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

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)

Will do.

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.

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

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