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

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

[Julia Evans via GitGitGadget]

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

diff --git a/Documentation/git.adoc b/Documentation/git.adoc
index 6f0075f918..3e886d3e1d 100644
--- a/Documentation/git.adoc
+++ b/Documentation/git.adoc
@@ -22,16 +22,18 @@ Git is a fast, scalable, distributed revision control system with an
 unusually rich command set that provides both high-level operations
 and full access to internals.
 
-See linkgit:gittutorial[7] to get started, then see
-linkgit:giteveryday[7] for a useful minimum set of
-commands.  The link:user-manual.html[Git User's Manual] has a more
-in-depth introduction.  See linkgit:gitdatamodel[7] if you want to
-learn about the data model and important terminology.
-
-After you mastered the basic concepts, you can come back to this
-page to learn what commands Git offers.  You can learn more about
-individual Git commands with "git help command".  linkgit:gitcli[7]
-manual page gives you an overview of the command-line command syntax.
+There are two ways to get help on any Git subcommand (replace "push"
+with the command you want help with):
+
+- `git push -h` for a short help
+- `git push --help` for the full documentation
+
+There are also guides explaining Git's concepts and more:
+
+- `git help` shows the most frequently used Git subcommands
+- `git help --guides` lists Git's concept guides
+- `git help --user-interfaces` lists guides for various
+  special files you can use to change Git's behaviour
 
 A formatted and hyperlinked copy of the latest Git documentation
 can be viewed at https://git.github.io/htmldocs/git.html

base-commit: 0f8e75abebff0877cae681a3d5ff31ac47f54220
-- 
gitgitgadget

Re: [PATCH] [doc] Use `man git` to teach users how to navigate the docs

[Ben Knoble]

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

Re: [PATCH] [doc] Use `man git` to teach users how to navigate the docs

[Junio C Hamano]

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

Re: [PATCH] [doc] Use `man git` to teach users how to navigate the docs

[Julia Evans]

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

Re: [PATCH] [doc] Use `man git` to teach users how to navigate the docs

[Junio C Hamano]

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

Re: [PATCH] [doc] Use `man git` to teach users how to navigate the docs

[Julia Evans]

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.

Re: [PATCH] [doc] Use `man git` to teach users how to navigate the docs

[Junio C Hamano]

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

[PATCH v2] doc: use `man git` to teach users how to navigate the docs

[Julia Evans via GitGitGadget]

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

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

Range-diff vs v1:

 1:  5da3881760 ! 1:  18f373a8f3 [doc] Use `man git` to teach users how to navigate the docs
     @@ Metadata
      Author: Julia Evans <julia@jvns.ca>
      
       ## Commit message ##
     -    [doc] Use `man git` to teach users how to navigate the docs
     +    doc: use `man git` to teach users how to navigate the docs
      
          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`
     @@ Documentation/git.adoc: Git is a fast, scalable, distributed revision control sy
      -commands.  The link:user-manual.html[Git User's Manual] has a more
      -in-depth introduction.  See linkgit:gitdatamodel[7] if you want to
      -learn about the data model and important terminology.
     --
     ++There are two ways to get help with any Git subcommand (replace "push"
     ++with the command you want help with):
     + 
      -After you mastered the basic concepts, you can come back to this
      -page to learn what commands Git offers.  You can learn more about
      -individual Git commands with "git help command".  linkgit:gitcli[7]
      -manual page gives you an overview of the command-line command syntax.
     -+There are two ways to get help on any Git subcommand (replace "push"
     -+with the command you want help with):
     -+
      +- `git push -h` for a short help
     -+- `git push --help` for the full documentation
     -+
     ++- `git push --help` or `git help push` for the full documentation
     + 
     +-A formatted and hyperlinked copy of the latest Git documentation
     +-can be viewed at https://git.github.io/htmldocs/git.html
     +-or https://git-scm.com/docs.
      +There are also guides explaining Git's concepts and more:
     -+
     + 
      +- `git help` shows the most frequently used Git subcommands
      +- `git help --guides` lists Git's concept guides
      +- `git help --user-interfaces` lists guides for various
      +  special files you can use to change Git's behaviour
     ++
     ++You can view an HTML version of the documentation with `git help --web`
     ++(for example `git help --web push`) or at https://git-scm.com/docs.
       
     - A formatted and hyperlinked copy of the latest Git documentation
     - can be viewed at https://git.github.io/htmldocs/git.html
     + OPTIONS
     + -------


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

diff --git a/Documentation/git.adoc b/Documentation/git.adoc
index 6f0075f918..6dfb829a7e 100644
--- a/Documentation/git.adoc
+++ b/Documentation/git.adoc
@@ -22,21 +22,21 @@ Git is a fast, scalable, distributed revision control system with an
 unusually rich command set that provides both high-level operations
 and full access to internals.
 
-See linkgit:gittutorial[7] to get started, then see
-linkgit:giteveryday[7] for a useful minimum set of
-commands.  The link:user-manual.html[Git User's Manual] has a more
-in-depth introduction.  See linkgit:gitdatamodel[7] if you want to
-learn about the data model and important terminology.
+There are two ways to get help with any Git subcommand (replace "push"
+with the command you want help with):
 
-After you mastered the basic concepts, you can come back to this
-page to learn what commands Git offers.  You can learn more about
-individual Git commands with "git help command".  linkgit:gitcli[7]
-manual page gives you an overview of the command-line command syntax.
+- `git push -h` for a short help
+- `git push --help` or `git help push` for the full documentation
 
-A formatted and hyperlinked copy of the latest Git documentation
-can be viewed at https://git.github.io/htmldocs/git.html
-or https://git-scm.com/docs.
+There are also guides explaining Git's concepts and more:
 
+- `git help` shows the most frequently used Git subcommands
+- `git help --guides` lists Git's concept guides
+- `git help --user-interfaces` lists guides for various
+  special files you can use to change Git's behaviour
+
+You can view an HTML version of the documentation with `git help --web`
+(for example `git help --web push`) or at https://git-scm.com/docs.
 
 OPTIONS
 -------

base-commit: 0f8e75abebff0877cae681a3d5ff31ac47f54220
-- 
gitgitgadget

Re: [PATCH v2] doc: use `man git` to teach users how to navigate the docs

[D. Ben Knoble]

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.

Re: [PATCH v2] doc: use `man git` to teach users how to navigate the docs

[Kristoffer Haugsbakk]

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]

Re: [PATCH v2] doc: use `man git` to teach users how to navigate the docs

[Julia Evans]

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

Re: [PATCH v2] doc: use `man git` to teach users how to navigate the docs

[Junio C Hamano]

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

Re: [PATCH v2] doc: use `man git` to teach users how to navigate the docs

[Julia Evans]

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.

Re: [PATCH v2] doc: use `man git` to teach users how to navigate the docs

[Junio C Hamano]

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

Re: [PATCH v2] doc: use `man git` to teach users how to navigate the docs

[Junio C Hamano]

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

Re: [PATCH v2] doc: use `man git` to teach users how to navigate the docs

[Julia Evans]

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

Re: [PATCH v2] doc: use `man git` to teach users how to navigate the docs

[Junio C Hamano]

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

Re: [PATCH v2] doc: use `man git` to teach users how to navigate the docs

[Julia Evans]

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.