mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Nieder <>
To: Frederick Eaton <>
Cc:, "Robert P. J. Day" <>
Subject: Re: de-alphabetizing the documentation
Date: Fri, 6 Jul 2018 14:16:00 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Frederick,

Frederick Eaton wrote:

> I am trying to learn how to use Git but I've been put off by not
> knowing where to start. I would like to start with the 'git' man page,
> but it lists the Git subcommands in alphabetical order, rather than in
> an order which would be useful for learners. For example, I'm not sure
> how often 'git bisect' is used, but it is strange to see it listed
> before 'git init' and 'git clone'.
> I wonder if someone familiar with Git could list the commands in an
> order which makes more sense for learning, for example in the order in
> which they were invented by Git developers,

That doesn't seem like a useful order pedagogically, but

>                                             or in the reverse order of
> frequency of use by a typical Git user.

That does.

Currently the commands are already broken into a few categories:

  High-level commands
    Main porcelain commands
    Ancillary commands
    Interacting with others
  Low-level commands
    Manipulation commands
    Interrogation commands
    Synching repositories
    Internal helper commands

While it's alphabetical within each section, overall it is not
alphabetical at all!

Alas, there are plenty of "Main porcelain commands", and I think that
is where your question comes from.  It would be nicer to list just five
to start, say.

Some of the most thoughtful documentation that comes with Git is at
It might be useful for inspiration.

Ideas?  If you start with a proposal, we're happy to help refine it.
People in the #git channel on (
might also be useful for inspiration in coming up with a proposal.

Each of us have our weaknesses for this kind of work: you're telling
me you're too new to have a sense of which commands are the first a
person would need to learn (and I have no reason to doubt you), while
many on this list would have the opposite problem of taking too much
for granted and not being able to put themselves in the mind of a
newcomer.  So we'll have to help each other.

tl/dr: if you come up with a proposed "first commands to learn"
category with some proposed commands to go in it, we'll be happy to
help you with the next steps.

> Finally, perhaps the same listing and/or reordering could be done for
> other important manual pages, like 'gitglossary'. Presumably
> 'gitglossary' should be sorted topologically, so that each term is
> defined prior to any terms depending on it.

Your help is welcome here as well.  Probably a similar kind of
categorization, with entries ordered either alphabetically or
according to some narrative in each section, would be the easiest to
maintain over time.


  reply	other threads:[~2018-07-06 21:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-06 20:04 de-alphabetizing the documentation frederik
2018-07-06 21:16 ` Jonathan Nieder [this message]
2018-07-06 21:18   ` Jonathan Nieder
2018-07-06 23:21     ` frederik
2018-07-06 23:47       ` Jonathan Nieder
2018-07-08  1:09         ` frederik
2018-07-24 19:52           ` frederik
2018-07-24 21:11             ` Jonathan Nieder
2018-08-11  2:30               ` frederik
2018-08-13 18:17                 ` Junio C Hamano
2019-02-19 17:54                   ` [PATCH 0/1] de-alphabetize command list Frederick Eaton
2019-02-21 18:05                     ` frederik
2019-03-11  9:04                       ` frederik
2019-03-11 14:38                         ` Jacob Keller
2019-02-19 17:54                   ` [PATCH] Prioritize list of commands appearing in git(1), via command-list.txt. Don't invoke 'sort' in Documentation/cmd-list.perl Frederick Eaton
2018-07-07  4:25       ` de-alphabetizing the documentation Theodore Y. Ts'o
2018-07-06 21:32   ` Eric Sunshine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).