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

[jvns]

Changes in v2:

• mention the git help push form too
• mention you can get HTML docs with git help --web push at the end to advertise git help's great features, and remove https://git.github.io/htmldocs/git.html since https://git-scm.com/docs has a nicer view and 3 different options is a lot.
• some minor wording changes
• fix commit message style (doc: not [doc])

Changes in v3: (just updates to the commit message)

• Add a sentence summarizing the goals "give a more realistic view of what the documentation actually provides."
• Explain why we're removing https://git.github.io/htmldocs/git.html, gitcli, and the user manual, and the data model
• Mention the plan to include the tutorial again here once we have one we're happy with

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.

[jvns]

/submit

[gitgitgadget]

Submitted as pull.2242.v2.git.1791317163584.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

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

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

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

[gitgitgadget]

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

On Tue, Oct 6, 2026 at 4:06 PM Julia Evans via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>     Changes in v2:
>
>      * mention the git help push form too
>      * mention you can get HTML docs with git help --web push at the end to
>        advertise git help's great features, and remove
>        https://git.github.io/htmldocs/git.html since
>        https://git-scm.com/docs has a nicer view and 3 different options is
>        a lot.
>      * some minor wording changes
>      * fix commit message style (doc: not [doc])

Thanks, personally I'm happy with this version.

[gitgitgadget]

"Kristoffer Haugsbakk" wrote on the Git mailing list (how to reply to this email):

On Tue, Oct 6, 2026, at 22:06, Julia Evans via GitGitGadget wrote:
> 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.

Yeah I can imagine.

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

I recall only relatively recently learning that `-h` is not just a
shorter way to type `--help`.

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

Right, aspirations are not good enough when it comes to the bread and
butter everyday howtos.

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

Okay, so now we don’t have to list out every guide that might be of
interest. That’s cool.

I see that this would conflict with my topic
kh/doc-gitbreaking-changes7.[1] Just would since my topic hasn’t
been integrated yet (RFC). I use the old style of mentioning the
new gitbreaking-changes(7) (“see <here> for ...”. I will remove
that change in order to stay consistent with this topic.

🔗 1: https://lore.kernel.org/git/CV_gitbrchanges7_please.d1c@m5gid.xyz/

>
> Signed-off-by: Julia Evans <julia@jvns.ca>
> ---
>     [doc] Use man git to teach users how to navigate the docs
>
>     Changes in v2:
>
>      * mention the git help push form too
>      * mention you can get HTML docs with git help --web push at the end to
>        advertise git help's great features, and remove
>        https://git.github.io/htmldocs/git.html since
>        https://git-scm.com/docs has a nicer view and 3 different options is
>        a lot.

Nitpick: Okay, but with the current commit message I don’t really
understand why the git.github.io link is gone. I have to guess that it
is an effective duplicate of git-scm or something since git-scm does
remain after this change.

>      * some minor wording changes
>      * fix commit message style (doc: not [doc])
>
>[snip]

[gitgitgadget]

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

> I recall only relatively recently learning that `-h` is not just a
> shorter way to type `--help`.

I just learned that recently too!

> Okay, so now we don’t have to list out every guide that might be of
> interest. That’s cool.
>
> I see that this would conflict with my topic
> kh/doc-gitbreaking-changes7.[1] Just would since my topic hasn’t
> been integrated yet (RFC). I use the old style of mentioning the
> new gitbreaking-changes(7) (“see <here> for ...”. I will remove
> that change in order to stay consistent with this topic.

> 🔗 1: https://lore.kernel.org/git/CV_gitbrchanges7_please.d1c@m5gid.xyz/

That makes sense to me, thanks! I saw that topic and funnily I've
been working on moving most of the content of `gitworkflows`
in the other direction (from the user facing manual pages to
the internal-only docs).

>>
>>      * mention the git help push form too
>>      * mention you can get HTML docs with git help --web push at the end to
>>        advertise git help's great features, and remove
>>        https://git.github.io/htmldocs/git.html since
>>        https://git-scm.com/docs has a nicer view and 3 different options is
>>        a lot.
>
> Nitpick: Okay, but with the current commit message I don’t really
> understand why the git.github.io link is gone. I have to guess that it
> is an effective duplicate of git-scm or something since git-scm does
> remain after this change.

Yep! It has the same content as https://git-scm.com as far as I know,
but without a lot of the nice features (a table of contents, an overview
of all the documentation, search, etc).

[gitgitgadget]

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

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

>> Nitpick: Okay, but with the current commit message I don’t really
>> understand why the git.github.io link is gone. I have to guess that it
>> is an effective duplicate of git-scm or something since git-scm does
>> remain after this change.
>
> Yep! It has the same content as https://git-scm.com as far as I know,

Correct.  That is direct rendition of what we ship.  git-scm.com has
some fruff around it (grouping and other meaningful usability
improvements besides coloring and fonts), but I do not know how
up-to-date the contents or the grouping is and how they are kept
synchronized to the originals at git.github.io/htmldocs/git.html.

[gitgitgadget]

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

On Wed, Oct 7, 2026, at 9:47 AM, Junio C Hamano wrote:
> "Julia Evans" <julia@jvns.ca> writes:
>
>>> Nitpick: Okay, but with the current commit message I don’t really
>>> understand why the git.github.io link is gone. I have to guess that it
>>> is an effective duplicate of git-scm or something since git-scm does
>>> remain after this change.
>>
>> Yep! It has the same content as https://git-scm.com as far as I know,
>
> Correct.  That is direct rendition of what we ship.  git-scm.com has
> some fruff around it (grouping and other meaningful usability
> improvements besides coloring and fonts), but I do not know how
> up-to-date the contents or the grouping is and how they are kept
> synchronized to the originals at git.github.io/htmldocs/git.html.

Yeah, the grouping at https://git-scm.com/docs is a bit out of date.
I'm not sure how to fix it in a satisfactory way.

[gitgitgadget]

This patch series was integrated into seen via git@2f06550.

[gitgitgadget]

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

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

> On Wed, Oct 7, 2026, at 9:47 AM, Junio C Hamano wrote:
>> "Julia Evans" <julia@jvns.ca> writes:
>>
>>>> Nitpick: Okay, but with the current commit message I don’t really
>>>> understand why the git.github.io link is gone. I have to guess that it
>>>> is an effective duplicate of git-scm or something since git-scm does
>>>> remain after this change.
>>>
>>> Yep! It has the same content as https://git-scm.com as far as I know,
>>
>> Correct.  That is direct rendition of what we ship.  git-scm.com has
>> some fruff around it (grouping and other meaningful usability
>> improvements besides coloring and fonts), but I do not know how
>> up-to-date the contents or the grouping is and how they are kept
>> synchronized to the originals at git.github.io/htmldocs/git.html.
>
> Yeah, the grouping at https://git-scm.com/docs is a bit out of date.
> I'm not sure how to fix it in a satisfactory way.

Another thing is I do not know how fresh the contents are.  I know
the one you are removing the reference to keeps up with the tip of
'main/master' so it may describe yet-to-be-released new features and
behaviours.  I am assuming that the one at git-scm.com is updated to
the latest released version, which may be more useful for general
audience.

[gitgitgadget]

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

"Julia Evans via GitGitGadget" <gitgitgadget@gmail.com> writes:

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

The text mentions removing 'tutorial' and 'everyday', but does
not explain why we no longer reference 'user-manual', 'datamodel',
and 'cli'.  The third iteration should justify this.  At least,
I recall that adding a reference to 'cli' early in the document was
a deliberate decision, and we should explain why it is no longer
relevant.  It would not be surprising if it has become obsolete
over the last decade, but we still need to spell out why it is no
longer appropriate to reference here.

I wholeheartedly agree with dropping 'everyday', which was written
before Git 1.0 back when we did not have much introductory material.
It was not aspirational, and while its choice of twenty commands
suited the workflows of the time, it outlived its usefulness long
ago.

Thanks.

[gitgitgadget]

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

On Wed, Oct 7, 2026, at 3:13 PM, Junio C Hamano wrote:
> "Julia Evans via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> 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.
>
> The text mentions removing 'tutorial' and 'everyday', but does
> not explain why we no longer reference 'user-manual', 'datamodel',
> and 'cli'.  The third iteration should justify this.  At least,
> I recall that adding a reference to 'cli' early in the document was
> a deliberate decision, and we should explain why it is no longer
> relevant.  It would not be surprising if it has become obsolete
> over the last decade, but we still need to spell out why it is no
> longer appropriate to reference here.

Thanks, can do. Here's my thought process:

- Removed 'cli' because (from my perspective as a user) it seems like
  something that's written for Git developers and not users, like
  with "Commands that support the enhanced option parser",
  how is a user supposed to know which commands support
  the enhanced parser? I think it makes sense as a guide to
  scripting Git but not for interactive use. Some of the bits on `diff`
  feel like they might belong in the `git diff` man page, not sure.
- Removed "user-manual" because it's outdated. The chapter on
  "Sharing development with others" explains how to use
  `git format-patch` which is not how most people collaborate with
  git.
- Once all the others were removed it seemed a bit out of place
  to mention `gitdatamodel`.

[gitgitgadget]

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

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

> - Removed 'cli' because (from my perspective as a user) it seems like
>   something that's written for Git developers and not users, like
>   with "Commands that support the enhanced option parser",
>   how is a user supposed to know which commands support
>   the enhanced parser? I think it makes sense as a guide to
>   scripting Git but not for interactive use. Some of the bits on `diff`
>   feel like they might belong in the `git diff` man page, not sure.

Perhaps updating cli so that it does not give a false smell of
getting written for a wrong audiences is a more productive
direction, though?  I do not think there is any other document that
tells users the simple "options first and then revs and then paths"
rule, for example.

> - Removed "user-manual" because it's outdated. The chapter on
>   "Sharing development with others" explains how to use
>   `git format-patch` which is not how most people collaborate with
>   git.

Yes, the was written in a very early days, and by a person who
worked in the Linux kernel circle.  I do not know about "not how
most people" part, but I would agree that "many users do not use"
would be a fair description of the modern world order.

> - Once all the others were removed it seemed a bit out of place
>   to mention `gitdatamodel`.

Not limited to the issue of where `gitdatamodel` should fit, I think
we probably should explain the goal of these change at a bit higher
level.  The original intention to refer to these things very early
in the documentation was to direct those readers who are not ready
to go into the list of git subcommands to those "introductory" text
and concepts guides, and encourage them to come back once they are
equipped with basic concepts and workflows.  I do not know if that
design actually helped or was harmful for the real-world learners,
but if we are shuffling the material we present early by removing
some and introducing others, we should explain what our overall
design of the presentation order is, for example.

Thanks.

[gitgitgadget]

This branch is now known as je/doc-promote-git-help.

[gitgitgadget]

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

On Wed, Oct 7, 2026, at 4:08 PM, Junio C Hamano wrote:
> "Julia Evans" <julia@jvns.ca> writes:
>
>> - Removed 'cli' because (from my perspective as a user) it seems like
>>   something that's written for Git developers and not users, like
>>   with "Commands that support the enhanced option parser",
>>   how is a user supposed to know which commands support
>>   the enhanced parser? I think it makes sense as a guide to
>>   scripting Git but not for interactive use. Some of the bits on `diff`
>>   feel like they might belong in the `git diff` man page, not sure.
>
> Perhaps updating cli so that it does not give a false smell of
> getting written for a wrong audiences is a more productive
> direction, though?  I do not think there is any other document that
> tells users the simple "options first and then revs and then paths"
> rule, for example.

If at some time in the future we update `gitcli` I think it could make
sense to put it back!

>> - Removed "user-manual" because it's outdated. The chapter on
>>   "Sharing development with others" explains how to use
>>   `git format-patch` which is not how most people collaborate with
>>   git.
>
> Yes, the was written in a very early days, and by a person who
> worked in the Linux kernel circle.  I do not know about "not how
> most people" part, but I would agree that "many users do not use"
> would be a fair description of the modern world order.
>
>> - Once all the others were removed it seemed a bit out of place
>>   to mention `gitdatamodel`.
>
> Not limited to the issue of where `gitdatamodel` should fit, I think
> we probably should explain the goal of these change at a bit higher
> level.  The original intention to refer to these things very early
> in the documentation was to direct those readers who are not ready
> to go into the list of git subcommands to those "introductory" text
> and concepts guides, and encourage them to come back once they are
> equipped with basic concepts and workflows.  I do not know if that
> design actually helped or was harmful for the real-world learners,
> but if we are shuffling the material we present early by removing
> some and introducing others, we should explain what our overall
> design of the presentation order is, for example.

As we rebuild some of this intro material we can bring it back in.
For example once we have a tutorial we're happy with I think it would
make sense to suggest that folks read it to learn Git.

If you're asking what I intend the overall design of the presentation order
to be, the goal is to bring the Git docs towards more of an
"every page is page one" design https://everypageispageone.com/the-book/ 
where on most pages we don't expect or require the reader to have read
any of the other documentation. So for the the most part there would be no
"presentation order". We'd instead provide links to more context for people
who are interested. This increased focus on linking is why I sent that patch
to make the AsciiDoc links work better in the HTML docs.

I think this kind of "every page is page one" structure would be both easier
to maintain and better matches what users want than a book like the user
manual, so it's a win/win.

In some cases (like the tutorial) I think it would make sense to have an order,
like "learn `git commit` before learning branching", but I think we should keep
those sequences very short. Ideally we would be able to get feedback from folks
learning Git from the tutorial to find out they would like to learn next.

[gitgitgadget]

There was a status update in the "Cooking" section about the branch je/doc-promote-git-help on the Git mailing list:

The earliest part of 'man git' has been rewritten to explain various
ways to use 'git help' to get help.

Expecting a reroll.
cf. <3a665230-b221-410b-9a58-96c01210aea0@app.fastmail.com>
source: <pull.2242.v2.git.1791317163584.gitgitgadget@gmail.com>