Use `man git` to teach users how to navigate the docs

From: Julia Evans <[email protected]>

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.

---
[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/[email protected]/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(-)

index 6f0075f918..3e886d3e1d 100644
@@ -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

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

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

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.

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.

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

From: Julia Evans <[email protected]>

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.

---
[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 <[email protected]>

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

index 6f0075f918..6dfb829a7e 100644
@@ -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

Thanks, personally I'm happy with this version.

Yeah I can imagine.

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

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

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/[email protected]/

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.

I just learned that recently too!

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

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

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.

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.

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.

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.

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.

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.

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

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.

From: Julia Evans <[email protected]>

Rewrite man git to give a more realistic view of what the documentation actually provides.

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 direct references to all the guides, for the following reasons:

* gittutorial and giteveryday are 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 goal is to mention the tutorial again when when we have a tutorial we're happy with.
* gitcli is not very useful for users. A lot of it is about scripting and internal details about the option parser.
* the user manual is outdated. The chapter on "Sharing development with others" explains how to use git format-patch which is not how most Git users collaborate with git.
* mentioning the data model feels out of place once everything else is removed

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

Mention git help --guides and git help --user-interfaces, since there are some important guides in there (like submodules) that are hard to discover.

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

Remove https://git.github.io/htmldocs/git.html since it points to the master version of the documentation. https://git-scm.com/ has the version from the latest release which is more likely to be useful.

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

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

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

Range-diff vs v2:

1: 18f373a8f3 ! 1: 6cb4390e53 doc: use man git to teach users how to navigate the docs
@@ Metadata
## Commit message ##
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
- doesn't make it easy to find out how to get help with using Git.
+ Rewrite man git to give a more realistic view of what the
+ documentation actually provides.

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.
+ Remove the direct references to all the guides, for the following
+ reasons:
+
+ * gittutorial and giteveryday are 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 goal is to mention the tutorial again when when we have a tutorial
+ we're happy with.
+ * gitcli is not very useful for users. A lot of it is about scripting
+ and internal details about the option parser.
+ * the user manual is outdated. The chapter on "Sharing development with
+ others" explains how to use git format-patch which is not how most
+ Git users collaborate with git.
+ * mentioning the data model feels out of place once everything else is
+ removed

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.
+ Mention git help --guides and git help --user-interfaces,
+ since there are some important guides in there (like submodules) that
+ are hard to discover.

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

+ Remove https://git.github.io/htmldocs/git.html since it points to the
+ master version of the documentation. https://git-scm.com/ has the
+ version from the latest release which is more likely to be useful.
+

## Documentation/git.adoc ##

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

index 6f0075f918..6dfb829a7e 100644
@@ -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

Thanks, queued.