git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Jacob Keller <jacob.keller@gmail.com>
To: frederik@ofb.net
Cc: Git mailing list <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Eric Sunshine <sunshine@sunshineco.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	"Theodore Y. Ts'o" <tytso@mit.edu>
Subject: Re: [PATCH 0/1] de-alphabetize command list
Date: Mon, 11 Mar 2019 07:38:02 -0700
Message-ID: <CA+P7+xpC5mDRx1ev-3ebGMEexgvLv-kDtM=9g35hRETOPo6c8g@mail.gmail.com> (raw)
In-Reply-To: <20190311090436.brdk7un7dto7rrhh@localhost>

On Mon, Mar 11, 2019 at 2:09 AM <frederik@ofb.net> wrote:
>
> Hey Git people,
>
> I didn't get a reply and I'm not sure what the appropriate ping
> interval is, or when I should conclude that no one is interested.
>
> There seemed to be some vaguely positive feedback before I embarked on
> this project. At the same time I don't want to pester anyone into
> applying patches in a disorganized fashion.
>
> I'm not subscribed to the mailing list so I apologize if I'm out of
> tune with a release cycle or current development thrust.
>
> Thanks,
>
> Frederick
>

FWIW, I felt like the changes in your proposed patch were good. I
haven't had more time to dig into reviewing it much though :(

-Jake

> On Thu, Feb 21, 2019 at 10:05:22AM -0800, frederik@ofb.net wrote:
> >I realized that it would probably be easier to discuss this proposal
> >if I attached the final command listing and the rendered manual page.
> >Please find them attached to this message.
> >
> >Thank you,
> >
> >Frederick
> >
> >On Tue, Feb 19, 2019 at 09:54:12AM -0800, Frederick Eaton wrote:
> >>This is a follow-up to my proposal to de-alphabetize the command
> >>listings in the git(1) manual page, from 6 July 2018.
> >>
> >>Some projects have manual page items listed in alphabetical order,
> >>some don't. As I argued in my proposal, I find it easier to learn from
> >>material which is not alphabetized. If this patch is accepted, I hope
> >>that it will make the Git documentation more accessible to myself and
> >>others.
> >>
> >>I produced the reordered command list in this patch using several
> >>sources, as indicated by comments in the new command-list.txt file.
> >>First, all the commands in the main part of "gittutorial(7)" appear in
> >>order, then the commands in giteveryday(7). Then appear additional
> >>commands from a friend's shell history, in reverse order of frequency.
> >>Then gittutorial-2(7), then gitcore-tutorial(7). After that there is a
> >>list of "guides", followed by about 100 commands not appearing in the
> >>earlier lists. I kept the guides and the remaining commands in their
> >>category groupings (guide, mainporcelain, ancillarymanipulators,
> >>etc.), but ordered the commands within each category according to my
> >>own judgment after skimming each manual page.
> >>
> >>To verify that the new list is a permutation of the most recent list,
> >>I use the following command (it should produce no output and exit 0):
> >>
> >>   diff <(git show master:command-list.txt | grep -v '^#' | sort ) <(cat command-list.txt | grep -v '^#' | sort)
> >>
> >>Note this patch changes the order of commands appearing in the
> >>generated file "command-list.h", which mostly seems to be used by
> >>"help.c". Probably due to the various occurrences of QSORT in
> >>"help.c", I think this reordering has no visible effect. I am willing
> >>to do any additional testing which may be recommended to ensure that
> >>this patch has no undesired consequences.
> >>
> >>Frederick Eaton (1):
> >> Prioritize list of commands appearing in git(1), via command-list.txt.
> >>   Don't invoke 'sort' in Documentation/cmd-list.perl.
> >>
> >>Documentation/cmd-list.perl |   2 +-
> >>command-list.txt            | 295 +++++++++++++++++++-----------------
> >>2 files changed, 158 insertions(+), 139 deletions(-)
> >>
> >>--
> >>2.20.1
> >>
>
> ># Command classification list
> ># ---------------------------
> ># All supported commands, builtin or external, must be described in
> ># here. This info is used to list commands in various places. Each
> ># command is on one line followed by one or more attributes.
> >#
> ># The first attribute group is mandatory and indicates the command
> ># type. This group includes:
> >#
> >#   mainporcelain
> >#   ancillarymanipulators
> >#   ancillaryinterrogators
> >#   foreignscminterface
> >#   plumbingmanipulators
> >#   plumbinginterrogators
> >#   synchingrepositories
> >#   synchelpers
> >#   purehelpers
> >#
> ># The type names are self explanatory. But if you want to see what
> ># command belongs to what group to get a better picture, have a look
> ># at "git" man page, "GIT COMMANDS" section.
> >#
> ># Commands of type mainporcelain can also optionally have one of these
> ># attributes:
> >#
> >#   init
> >#   worktree
> >#   info
> >#   history
> >#   remote
> >#
> ># These commands are considered "common" and will show up in "git
> ># help" output in groups. Uncommon porcelain commands must not
> ># specify any of these attributes.
> >#
> ># "complete" attribute is used to mark that the command should be
> ># completable by git-completion.bash. Note that by default,
> ># mainporcelain commands are completable so you don't need this
> ># attribute.
> >#
> ># As part of the Git man page list, the man(5/7) guides are also
> ># specified here, which can only have "guide" attribute and nothing
> ># else.
> >#
> ># February 2019: This list had been sorted alphabetically but has been
> ># reordered to make it easier for people to learn from the main git(1)
> ># manual page. The new ordering is according to approximate usefulness
> ># / frequency of use / order of use, with some grouping by topic. The
> ># idea is to make it possible to read the manual page from beginning
> ># to end and see the most important commands first, rather than
> ># getting them in alphabetical order - in other words, to make the
> ># manual page more like a table of contents and less like an index.
> ># Please consider this when adding new commands.
> >#
> >### command list (do not change this line, also do not change alignment)
> ># command name                          category [category] [category]
> ># From gittutorial
> >git-help                                ancillaryinterrogators          complete
> >git-config                              ancillarymanipulators           complete
> >git-clone                               mainporcelain           init
> >git-init                                mainporcelain           init
> >git-add                                 mainporcelain           worktree
> >git-commit                              mainporcelain           history
> >git-diff                                mainporcelain           history
> >git-status                              mainporcelain           info
> >git-log                                 mainporcelain           info
> >git-branch                              mainporcelain           history
> >git-checkout                            mainporcelain           history
> >git-merge                               mainporcelain           history
> >gitk                                    mainporcelain
> >git-pull                                mainporcelain           remote
> >git-fetch                               mainporcelain           remote
> ># From tutorial NEXT STEPS
> >git-format-patch                        mainporcelain
> >git-bisect                              mainporcelain           info
> >giteveryday                             guide
> >gitworkflows                            guide
> >gitcvs-migration                        guide
> ># From giteveryday
> >git-reset                               mainporcelain           worktree
> >git-rebase                              mainporcelain           history
> >git-tag                                 mainporcelain           history
> >git-push                                mainporcelain           remote
> >git-send-email                          foreignscminterface             complete
> >git-request-pull                        foreignscminterface             complete
> >git-am                                  mainporcelain
> >git-revert                              mainporcelain
> >git-daemon                              synchingrepositories
> >git-shell                               synchelpers
> >git-http-backend                        synchingrepositories
> >gitweb                                  ancillaryinterrogators
> ># From user feedback
> >git-grep                                mainporcelain           info
> >git-show                                mainporcelain           info
> >git-submodule                           mainporcelain
> >git-cherry-pick                         mainporcelain
> >git-clean                               mainporcelain
> ># From gittutorial-2
> >git-cat-file                            plumbinginterrogators
> >git-ls-tree                             plumbinginterrogators
> >git-ls-files                            plumbinginterrogators
> >gitcore-tutorial                        guide
> >gitglossary                             guide
> ># From gitcore-tutorial
> >git-update-index                        plumbingmanipulators
> >git-diff-files                          plumbinginterrogators
> >git-write-tree                          plumbingmanipulators
> >git-read-tree                           plumbingmanipulators
> >git-checkout-index                      plumbingmanipulators
> >git-show-branch                         ancillaryinterrogators          complete
> >git-name-rev                            plumbinginterrogators
> >git-merge-index                         plumbingmanipulators
> >git-repack                              ancillarymanipulators           complete
> >git-prune-packed                        plumbingmanipulators
> >git-update-server-info                  synchingrepositories
> >git-prune                               ancillarymanipulators
> >git-cherry                              plumbinginterrogators          complete
> ># Guides, reordered
> >gittutorial                             guide
> >gittutorial-2                           guide
> >gitrevisions                            guide
> >gitignore                               guide
> >gitcli                                  guide
> >gitrepository-layout                    guide
> >gitdiffcore                             guide
> >gitmodules                              guide
> >githooks                                guide
> >gitnamespaces                           guide
> >gitattributes                           guide
> ># All other commands, sorted by man page category and then by
> ># approximate priority
> >git-stash                               mainporcelain
> >git-rm                                  mainporcelain           worktree
> >git-mv                                  mainporcelain           worktree
> >git-gui                                 mainporcelain
> >git-citool                              mainporcelain
> >git-archive                             mainporcelain
> >git-shortlog                            mainporcelain
> >git-describe                            mainporcelain
> >git-gc                                  mainporcelain
> >git-notes                               mainporcelain
> >git-worktree                            mainporcelain
> >git-bundle                              mainporcelain
> >git-range-diff                          mainporcelain
> >git-stage                                                               complete
> >git-reflog                              ancillarymanipulators           complete
> >git-remote                              ancillarymanipulators           complete
> >git-mergetool                           ancillarymanipulators           complete
> >git-filter-branch                       ancillarymanipulators
> >git-replace                             ancillarymanipulators           complete
> >git-fast-export                         ancillarymanipulators
> >git-fast-import                         ancillarymanipulators
> >git-pack-refs                           ancillarymanipulators
> >git-cvsimport                           foreignscminterface
> >git-cvsserver                           foreignscminterface
> >git-cvsexportcommit                     foreignscminterface
> >git-svn                                 foreignscminterface
> >git-p4                                  foreignscminterface
> >git-quiltimport                         foreignscminterface
> >git-archimport                          foreignscminterface
> >git-imap-send                           foreignscminterface
> >git-apply                               plumbingmanipulators            complete
> >git-merge-file                          plumbingmanipulators
> >git-mktag                               plumbingmanipulators
> >git-hash-object                         plumbingmanipulators
> >git-update-ref                          plumbingmanipulators
> >git-symbolic-ref                        plumbingmanipulators
> >git-commit-tree                         plumbingmanipulators
> >git-commit-graph                        plumbingmanipulators
> >git-mktree                              plumbingmanipulators
> >git-pack-objects                        plumbingmanipulators
> >git-unpack-objects                      plumbingmanipulators
> >git-index-pack                          plumbingmanipulators
> >git-multi-pack-index                    plumbingmanipulators
> >git-blame                               ancillaryinterrogators          complete
> >git-annotate                            ancillaryinterrogators
> >git-instaweb                            ancillaryinterrogators          complete
> >git-rerere                              ancillaryinterrogators
> >git-fsck                                ancillaryinterrogators          complete
> >git-whatchanged                         ancillaryinterrogators          complete
> >git-difftool                            ancillaryinterrogators          complete
> >git-merge-tree                          ancillaryinterrogators
> >git-count-objects                       ancillaryinterrogators
> >git-verify-commit                       ancillaryinterrogators
> >git-verify-tag                          ancillaryinterrogators
> >git-send-pack                           synchingrepositories
> >git-fetch-pack                          synchingrepositories
> >git-parse-remote                        synchelpers
> >git-receive-pack                        synchelpers
> >git-upload-pack                         synchelpers
> >git-upload-archive                      synchelpers
> >git-http-fetch                          synchelpers
> >git-http-push                           synchelpers
> >git-var                                 plumbinginterrogators
> >git-rev-list                            plumbinginterrogators
> >git-rev-parse                           plumbinginterrogators
> >git-for-each-ref                        plumbinginterrogators
> >git-show-ref                            plumbinginterrogators
> >git-ls-remote                           plumbinginterrogators
> >git-diff-tree                           plumbinginterrogators
> >git-diff-index                          plumbinginterrogators
> >git-merge-base                          plumbinginterrogators
> >git-verify-pack                         plumbinginterrogators
> >git-pack-redundant                      plumbinginterrogators
> >git-unpack-file                         plumbinginterrogators
> >git-show-index                          plumbinginterrogators
> >git-get-tar-commit-id                   plumbinginterrogators
> >git-merge-one-file                      purehelpers
> >git-sh-setup                            purehelpers
> >git-check-ref-format                    purehelpers
> >git-check-ignore                        purehelpers
> >git-check-attr                          purehelpers
> >git-credential                          purehelpers
> >git-credential-cache                    purehelpers
> >git-credential-store                    purehelpers
> >git-fmt-merge-msg                       purehelpers
> >git-check-mailmap                       purehelpers
> >git-mailsplit                           purehelpers
> >git-mailinfo                            purehelpers
> >git-interpret-trailers                  purehelpers
> >git-column                              purehelpers
> >git-stripspace                          purehelpers
> >git-patch-id                            purehelpers
> >git-sh-i18n                             purehelpers
>
> >GIT(1)                            Git Manual                            GIT(1)
> >
> >NAME
> >       git - the stupid content tracker
> >
> >SYNOPSIS
> >       git [--version] [--help] [-C <path>] [-c <name>=<value>]
> >           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
> >           [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare]
> >           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
> >           [--super-prefix=<path>]
> >           <command> [<args>]
> >
> >DESCRIPTION
> >       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 gittutorial(7) to get started, then see giteveryday(7) for a useful
> >       minimum set of commands. The Git User's Manual[1] has a more in-depth
> >       introduction.
> >
> >       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". gitcli(7) manual page gives you
> >       an overview of the command-line command syntax.
> >
> >       A formatted and hyperlinked copy of the latest Git documentation can be
> >       viewed at https://git.github.io/htmldocs/git.html.
> >
> >OPTIONS
> >       --version
> >           Prints the Git suite version that the git program came from.
> >
> >       --help
> >           Prints the synopsis and a list of the most commonly used commands.
> >           If the option --all or -a is given then all available commands are
> >           printed. If a Git command is named this option will bring up the
> >           manual page for that command.
> >
> >           Other options are available to control how the manual page is
> >           displayed. See git-help(1) for more information, because git --help
> >           ...  is converted internally into git help ....
> >
> >       -C <path>
> >           Run as if git was started in <path> instead of the current working
> >           directory. When multiple -C options are given, each subsequent
> >           non-absolute -C <path> is interpreted relative to the preceding -C
> >           <path>.
> >
> >           This option affects options that expect path name like --git-dir
> >           and --work-tree in that their interpretations of the path names
> >           would be made relative to the working directory caused by the -C
> >           option. For example the following invocations are equivalent:
> >
> >               git --git-dir=a.git --work-tree=b -C c status
> >               git --git-dir=c/a.git --work-tree=c/b status
> >
> >       -c <name>=<value>
> >           Pass a configuration parameter to the command. The value given will
> >           override values from configuration files. The <name> is expected in
> >           the same format as listed by git config (subkeys separated by
> >           dots).
> >
> >           Note that omitting the = in git -c foo.bar ...  is allowed and sets
> >           foo.bar to the boolean true value (just like [foo]bar would in a
> >           config file). Including the equals but with an empty value (like
> >           git -c foo.bar= ...) sets foo.bar to the empty string which git
> >           config --type=bool will convert to false.
> >
> >       --exec-path[=<path>]
> >           Path to wherever your core Git programs are installed. This can
> >           also be controlled by setting the GIT_EXEC_PATH environment
> >           variable. If no path is given, git will print the current setting
> >           and then exit.
> >
> >       --html-path
> >           Print the path, without trailing slash, where Git's HTML
> >           documentation is installed and exit.
> >
> >       --man-path
> >           Print the manpath (see man(1)) for the man pages for this version
> >           of Git and exit.
> >
> >       --info-path
> >           Print the path where the Info files documenting this version of Git
> >           are installed and exit.
> >
> >       -p, --paginate
> >           Pipe all output into less (or if set, $PAGER) if standard output is
> >           a terminal. This overrides the pager.<cmd> configuration options
> >           (see the "Configuration Mechanism" section below).
> >
> >       -P, --no-pager
> >           Do not pipe Git output into a pager.
> >
> >       --git-dir=<path>
> >           Set the path to the repository. This can also be controlled by
> >           setting the GIT_DIR environment variable. It can be an absolute
> >           path or relative path to current working directory.
> >
> >       --work-tree=<path>
> >           Set the path to the working tree. It can be an absolute path or a
> >           path relative to the current working directory. This can also be
> >           controlled by setting the GIT_WORK_TREE environment variable and
> >           the core.worktree configuration variable (see core.worktree in git-
> >           config(1) for a more detailed discussion).
> >
> >       --namespace=<path>
> >           Set the Git namespace. See gitnamespaces(7) for more details.
> >           Equivalent to setting the GIT_NAMESPACE environment variable.
> >
> >       --super-prefix=<path>
> >           Currently for internal use only. Set a prefix which gives a path
> >           from above a repository down to its root. One use is to give
> >           submodules context about the superproject that invoked it.
> >
> >       --bare
> >           Treat the repository as a bare repository. If GIT_DIR environment
> >           is not set, it is set to the current working directory.
> >
> >       --no-replace-objects
> >           Do not use replacement refs to replace Git objects. See git-
> >           replace(1) for more information.
> >
> >       --literal-pathspecs
> >           Treat pathspecs literally (i.e. no globbing, no pathspec magic).
> >           This is equivalent to setting the GIT_LITERAL_PATHSPECS environment
> >           variable to 1.
> >
> >       --glob-pathspecs
> >           Add "glob" magic to all pathspec. This is equivalent to setting the
> >           GIT_GLOB_PATHSPECS environment variable to 1. Disabling globbing on
> >           individual pathspecs can be done using pathspec magic ":(literal)"
> >
> >       --noglob-pathspecs
> >           Add "literal" magic to all pathspec. This is equivalent to setting
> >           the GIT_NOGLOB_PATHSPECS environment variable to 1. Enabling
> >           globbing on individual pathspecs can be done using pathspec magic
> >           ":(glob)"
> >
> >       --icase-pathspecs
> >           Add "icase" magic to all pathspec. This is equivalent to setting
> >           the GIT_ICASE_PATHSPECS environment variable to 1.
> >
> >       --no-optional-locks
> >           Do not perform optional operations that require locks. This is
> >           equivalent to setting the GIT_OPTIONAL_LOCKS to 0.
> >
> >       --list-cmds=group[,group...]
> >           List commands by group. This is an internal/experimental option and
> >           may change or be removed in the future. Supported groups are:
> >           builtins, parseopt (builtin commands that use parse-options), main
> >           (all commands in libexec directory), others (all other commands in
> >           $PATH that have git- prefix), list-<category> (see categories in
> >           command-list.txt), nohelpers (exclude helper commands), alias and
> >           config (retrieve command list from config variable
> >           completion.commands)
> >
> >GIT COMMANDS
> >       We divide Git into high level ("porcelain") commands and low level
> >       ("plumbing") commands.
> >
> >HIGH-LEVEL COMMANDS (PORCELAIN)
> >       We separate the porcelain commands into the main commands and some
> >       ancillary user utilities.
> >
> >   Main porcelain commands
> >       git-clone(1)
> >           Clone a repository into a new directory.
> >
> >       git-init(1)
> >           Create an empty Git repository or reinitialize an existing one.
> >
> >       git-add(1)
> >           Add file contents to the index.
> >
> >       git-commit(1)
> >           Record changes to the repository.
> >
> >       git-diff(1)
> >           Show changes between commits, commit and working tree, etc.
> >
> >       git-status(1)
> >           Show the working tree status.
> >
> >       git-log(1)
> >           Show commit logs.
> >
> >       git-branch(1)
> >           List, create, or delete branches.
> >
> >       git-checkout(1)
> >           Switch branches or restore working tree files.
> >
> >       git-merge(1)
> >           Join two or more development histories together.
> >
> >       gitk(1)
> >           The Git repository browser.
> >
> >       git-pull(1)
> >           Fetch from and integrate with another repository or a local branch.
> >
> >       git-fetch(1)
> >           Download objects and refs from another repository.
> >
> >       git-format-patch(1)
> >           Prepare patches for e-mail submission.
> >
> >       git-bisect(1)
> >           Use binary search to find the commit that introduced a bug.
> >
> >       git-reset(1)
> >           Reset current HEAD to the specified state.
> >
> >       git-rebase(1)
> >           Reapply commits on top of another base tip.
> >
> >       git-tag(1)
> >           Create, list, delete or verify a tag object signed with GPG.
> >
> >       git-push(1)
> >           Update remote refs along with associated objects.
> >
> >       git-am(1)
> >           Apply a series of patches from a mailbox.
> >
> >       git-revert(1)
> >           Revert some existing commits.
> >
> >       git-grep(1)
> >           Print lines matching a pattern.
> >
> >       git-show(1)
> >           Show various types of objects.
> >
> >       git-submodule(1)
> >           Initialize, update or inspect submodules.
> >
> >       git-cherry-pick(1)
> >           Apply the changes introduced by some existing commits.
> >
> >       git-clean(1)
> >           Remove untracked files from the working tree.
> >
> >       git-stash(1)
> >           Stash the changes in a dirty working directory away.
> >
> >       git-rm(1)
> >           Remove files from the working tree and from the index.
> >
> >       git-mv(1)
> >           Move or rename a file, a directory, or a symlink.
> >
> >       git-gui(1)
> >           A portable graphical interface to Git.
> >
> >       git-citool(1)
> >           Graphical alternative to git-commit.
> >
> >       git-archive(1)
> >           Create an archive of files from a named tree.
> >
> >       git-shortlog(1)
> >           Summarize git log output.
> >
> >       git-describe(1)
> >           Give an object a human readable name based on an available ref.
> >
> >       git-gc(1)
> >           Cleanup unnecessary files and optimize the local repository.
> >
> >       git-notes(1)
> >           Add or inspect object notes.
> >
> >       git-worktree(1)
> >           Manage multiple working trees.
> >
> >       git-bundle(1)
> >           Move objects and refs by archive.
> >
> >       git-range-diff(1)
> >           Compare two commit ranges (e.g. two versions of a branch).
> >
> >   Ancillary Commands
> >       Manipulators:
> >
> >       git-config(1)
> >           Get and set repository or global options.
> >
> >       git-repack(1)
> >           Pack unpacked objects in a repository.
> >
> >       git-prune(1)
> >           Prune all unreachable objects from the object database.
> >
> >       git-reflog(1)
> >           Manage reflog information.
> >
> >       git-remote(1)
> >           Manage set of tracked repositories.
> >
> >       git-mergetool(1)
> >           Run merge conflict resolution tools to resolve merge conflicts.
> >
> >       git-filter-branch(1)
> >           Rewrite branches.
> >
> >       git-replace(1)
> >           Create, list, delete refs to replace objects.
> >
> >       git-fast-export(1)
> >           Git data exporter.
> >
> >       git-fast-import(1)
> >           Backend for fast Git data importers.
> >
> >       git-pack-refs(1)
> >           Pack heads and tags for efficient repository access.
> >
> >       Interrogators:
> >
> >       git-help(1)
> >           Display help information about Git.
> >
> >       gitweb(1)
> >           Git web interface (web frontend to Git repositories).
> >
> >       git-show-branch(1)
> >           Show branches and their commits.
> >
> >       git-blame(1)
> >           Show what revision and author last modified each line of a file.
> >
> >       git-annotate(1)
> >           Annotate file lines with commit information.
> >
> >       git-instaweb(1)
> >           Instantly browse your working repository in gitweb.
> >
> >       git-rerere(1)
> >           Reuse recorded resolution of conflicted merges.
> >
> >       git-fsck(1)
> >           Verifies the connectivity and validity of the objects in the
> >           database.
> >
> >       git-whatchanged(1)
> >           Show logs with difference each commit introduces.
> >
> >       git-difftool(1)
> >           Show changes using common diff tools.
> >
> >       git-merge-tree(1)
> >           Show three-way merge without touching index.
> >
> >       git-count-objects(1)
> >           Count unpacked number of objects and their disk consumption.
> >
> >       git-verify-commit(1)
> >           Check the GPG signature of commits.
> >
> >       git-verify-tag(1)
> >           Check the GPG signature of tags.
> >
> >   Interacting with Others
> >       These commands are to interact with foreign SCM and with other people
> >       via patch over e-mail.
> >
> >       git-send-email(1)
> >           Send a collection of patches as emails.
> >
> >       git-request-pull(1)
> >           Generates a summary of pending changes.
> >
> >       git-cvsimport(1)
> >           Salvage your data out of another SCM people love to hate.
> >
> >       git-cvsserver(1)
> >           A CVS server emulator for Git.
> >
> >       git-cvsexportcommit(1)
> >           Export a single commit to a CVS checkout.
> >
> >       git-svn(1)
> >           Bidirectional operation between a Subversion repository and Git.
> >
> >       git-p4(1)
> >           Import from and submit to Perforce repositories.
> >
> >       git-quiltimport(1)
> >           Applies a quilt patchset onto the current branch.
> >
> >       git-archimport(1)
> >           Import a GNU Arch repository into Git.
> >
> >       git-imap-send(1)
> >           Send a collection of patches from stdin to an IMAP folder.
> >
> >LOW-LEVEL COMMANDS (PLUMBING)
> >       Although Git includes its own porcelain layer, its low-level commands
> >       are sufficient to support development of alternative porcelains.
> >       Developers of such porcelains might start by reading about git-update-
> >       index(1) and git-read-tree(1).
> >
> >       The interface (input, output, set of options and the semantics) to
> >       these low-level commands are meant to be a lot more stable than
> >       Porcelain level commands, because these commands are primarily for
> >       scripted use. The interface to Porcelain commands on the other hand are
> >       subject to change in order to improve the end user experience.
> >
> >       The following description divides the low-level commands into commands
> >       that manipulate objects (in the repository, index, and working tree),
> >       commands that interrogate and compare objects, and commands that move
> >       objects and references between repositories.
> >
> >   Manipulation commands
> >       git-update-index(1)
> >           Register file contents in the working tree to the index.
> >
> >       git-write-tree(1)
> >           Create a tree object from the current index.
> >
> >       git-read-tree(1)
> >           Reads tree information into the index.
> >
> >       git-checkout-index(1)
> >           Copy files from the index to the working tree.
> >
> >       git-merge-index(1)
> >           Run a merge for files needing merging.
> >
> >       git-prune-packed(1)
> >           Remove extra objects that are already in pack files.
> >
> >       git-apply(1)
> >           Apply a patch to files and/or to the index.
> >
> >       git-merge-file(1)
> >           Run a three-way file merge.
> >
> >       git-mktag(1)
> >           Creates a tag object.
> >
> >       git-hash-object(1)
> >           Compute object ID and optionally creates a blob from a file.
> >
> >       git-update-ref(1)
> >           Update the object name stored in a ref safely.
> >
> >       git-symbolic-ref(1)
> >           Read, modify and delete symbolic refs.
> >
> >       git-commit-tree(1)
> >           Create a new commit object.
> >
> >       git-commit-graph(1)
> >           Write and verify Git commit-graph files.
> >
> >       git-mktree(1)
> >           Build a tree-object from ls-tree formatted text.
> >
> >       git-pack-objects(1)
> >           Create a packed archive of objects.
> >
> >       git-unpack-objects(1)
> >           Unpack objects from a packed archive.
> >
> >       git-index-pack(1)
> >           Build pack index file for an existing packed archive.
> >
> >       git-multi-pack-index(1)
> >           Write and verify multi-pack-indexes.
> >
> >   Interrogation commands
> >       git-cat-file(1)
> >           Provide content or type and size information for repository
> >           objects.
> >
> >       git-ls-tree(1)
> >           List the contents of a tree object.
> >
> >       git-ls-files(1)
> >           Show information about files in the index and the working tree.
> >
> >       git-diff-files(1)
> >           Compares files in the working tree and the index.
> >
> >       git-name-rev(1)
> >           Find symbolic names for given revs.
> >
> >       git-cherry(1)
> >           Find commits yet to be applied to upstream.
> >
> >       git-var(1)
> >           Show a Git logical variable.
> >
> >       git-rev-list(1)
> >           Lists commit objects in reverse chronological order.
> >
> >       git-rev-parse(1)
> >           Pick out and massage parameters.
> >
> >       git-for-each-ref(1)
> >           Output information on each ref.
> >
> >       git-show-ref(1)
> >           List references in a local repository.
> >
> >       git-ls-remote(1)
> >           List references in a remote repository.
> >
> >       git-diff-tree(1)
> >           Compares the content and mode of blobs found via two tree objects.
> >
> >       git-diff-index(1)
> >           Compare a tree to the working tree or index.
> >
> >       git-merge-base(1)
> >           Find as good common ancestors as possible for a merge.
> >
> >       git-verify-pack(1)
> >           Validate packed Git archive files.
> >
> >       git-pack-redundant(1)
> >           Find redundant pack files.
> >
> >       git-unpack-file(1)
> >           Creates a temporary file with a blob's contents.
> >
> >       git-show-index(1)
> >           Show packed archive index.
> >
> >       git-get-tar-commit-id(1)
> >           Extract commit ID from an archive created using git-archive.
> >
> >       In general, the interrogate commands do not touch the files in the
> >       working tree.
> >
> >   Synching repositories
> >       git-daemon(1)
> >           A really simple server for Git repositories.
> >
> >       git-http-backend(1)
> >           Server side implementation of Git over HTTP.
> >
> >       git-update-server-info(1)
> >           Update auxiliary info file to help dumb servers.
> >
> >       git-send-pack(1)
> >           Push objects over Git protocol to another repository.
> >
> >       git-fetch-pack(1)
> >           Receive missing objects from another repository.
> >
> >       The following are helper commands used by the above; end users
> >       typically do not use them directly.
> >
> >       git-shell(1)
> >           Restricted login shell for Git-only SSH access.
> >
> >       git-parse-remote(1)
> >           Routines to help parsing remote repository access parameters.
> >
> >       git-receive-pack(1)
> >           Receive what is pushed into the repository.
> >
> >       git-upload-pack(1)
> >           Send objects packed back to git-fetch-pack.
> >
> >       git-upload-archive(1)
> >           Send archive back to git-archive.
> >
> >       git-http-fetch(1)
> >           Download from a remote Git repository via HTTP.
> >
> >       git-http-push(1)
> >           Push objects over HTTP/DAV to another repository.
> >
> >   Internal helper commands
> >       These are internal helper commands used by other commands; end users
> >       typically do not use them directly.
> >
> >       git-merge-one-file(1)
> >           The standard helper program to use with git-merge-index.
> >
> >       git-sh-setup(1)
> >           Common Git shell script setup code.
> >
> >       git-check-ref-format(1)
> >           Ensures that a reference name is well formed.
> >
> >       git-check-ignore(1)
> >           Debug gitignore / exclude files.
> >
> >       git-check-attr(1)
> >           Display gitattributes information.
> >
> >       git-credential(1)
> >           Retrieve and store user credentials.
> >
> >       git-credential-cache(1)
> >           Helper to temporarily store passwords in memory.
> >
> >       git-credential-store(1)
> >           Helper to store credentials on disk.
> >
> >       git-fmt-merge-msg(1)
> >           Produce a merge commit message.
> >
> >       git-check-mailmap(1)
> >           Show canonical names and email addresses of contacts.
> >
> >       git-mailsplit(1)
> >           Simple UNIX mbox splitter program.
> >
> >       git-mailinfo(1)
> >           Extracts patch and authorship from a single e-mail message.
> >
> >       git-interpret-trailers(1)
> >           add or parse structured information in commit messages.
> >
> >       git-column(1)
> >           Display data in columns.
> >
> >       git-stripspace(1)
> >           Remove unnecessary whitespace.
> >
> >       git-patch-id(1)
> >           Compute unique ID for a patch.
> >
> >       git-sh-i18n(1)
> >           Git's i18n setup code for shell scripts.
> >
> >CONFIGURATION MECHANISM
> >       Git uses a simple text format to store customizations that are per
> >       repository and are per user. Such a configuration file may look like
> >       this:
> >
> >           #
> >           # A '#' or ';' character indicates a comment.
> >           #
> >
> >           ; core variables
> >           [core]
> >                   ; Don't trust file modes
> >                   filemode = false
> >
> >           ; user identity
> >           [user]
> >                   name = "Junio C Hamano"
> >                   email = "gitster@pobox.com"
> >
> >       Various commands read from the configuration file and adjust their
> >       operation accordingly. See git-config(1) for a list and more details
> >       about the configuration mechanism.
> >
> >IDENTIFIER TERMINOLOGY
> >       <object>
> >           Indicates the object name for any type of object.
> >
> >       <blob>
> >           Indicates a blob object name.
> >
> >       <tree>
> >           Indicates a tree object name.
> >
> >       <commit>
> >           Indicates a commit object name.
> >
> >       <tree-ish>
> >           Indicates a tree, commit or tag object name. A command that takes a
> >           <tree-ish> argument ultimately wants to operate on a <tree> object
> >           but automatically dereferences <commit> and <tag> objects that
> >           point at a <tree>.
> >
> >       <commit-ish>
> >           Indicates a commit or tag object name. A command that takes a
> >           <commit-ish> argument ultimately wants to operate on a <commit>
> >           object but automatically dereferences <tag> objects that point at a
> >           <commit>.
> >
> >       <type>
> >           Indicates that an object type is required. Currently one of: blob,
> >           tree, commit, or tag.
> >
> >       <file>
> >           Indicates a filename - almost always relative to the root of the
> >           tree structure GIT_INDEX_FILE describes.
> >
> >SYMBOLIC IDENTIFIERS
> >       Any Git command accepting any <object> can also use the following
> >       symbolic notation:
> >
> >       HEAD
> >           indicates the head of the current branch.
> >
> >       <tag>
> >           a valid tag name (i.e. a refs/tags/<tag> reference).
> >
> >       <head>
> >           a valid head name (i.e. a refs/heads/<head> reference).
> >
> >       For a more complete list of ways to spell object names, see "SPECIFYING
> >       REVISIONS" section in gitrevisions(7).
> >
> >FILE/DIRECTORY STRUCTURE
> >       Please see the gitrepository-layout(5) document.
> >
> >       Read githooks(5) for more details about each hook.
> >
> >       Higher level SCMs may provide and manage additional information in the
> >       $GIT_DIR.
> >
> >TERMINOLOGY
> >       Please see gitglossary(7).
> >
> >ENVIRONMENT VARIABLES
> >       Various Git commands use the following environment variables:
> >
> >   The Git Repository
> >       These environment variables apply to all core Git commands. Nb: it is
> >       worth noting that they may be used/overridden by SCMS sitting above Git
> >       so take care if using a foreign front-end.
> >
> >       GIT_INDEX_FILE
> >           This environment allows the specification of an alternate index
> >           file. If not specified, the default of $GIT_DIR/index is used.
> >
> >       GIT_INDEX_VERSION
> >           This environment variable allows the specification of an index
> >           version for new repositories. It won't affect existing index files.
> >           By default index file version 2 or 3 is used. See git-update-
> >           index(1) for more information.
> >
> >       GIT_OBJECT_DIRECTORY
> >           If the object storage directory is specified via this environment
> >           variable then the sha1 directories are created underneath -
> >           otherwise the default $GIT_DIR/objects directory is used.
> >
> >       GIT_ALTERNATE_OBJECT_DIRECTORIES
> >           Due to the immutable nature of Git objects, old objects can be
> >           archived into shared, read-only directories. This variable
> >           specifies a ":" separated (on Windows ";" separated) list of Git
> >           object directories which can be used to search for Git objects. New
> >           objects will not be written to these directories.
> >
> >           Entries that begin with " (double-quote) will be interpreted as
> >           C-style quoted paths, removing leading and trailing double-quotes
> >           and respecting backslash escapes. E.g., the value
> >           "path-with-\"-and-:-in-it":vanilla-path has two paths:
> >           path-with-"-and-:-in-it and vanilla-path.
> >
> >       GIT_DIR
> >           If the GIT_DIR environment variable is set then it specifies a path
> >           to use instead of the default .git for the base of the repository.
> >           The --git-dir command-line option also sets this value.
> >
> >       GIT_WORK_TREE
> >           Set the path to the root of the working tree. This can also be
> >           controlled by the --work-tree command-line option and the
> >           core.worktree configuration variable.
> >
> >       GIT_NAMESPACE
> >           Set the Git namespace; see gitnamespaces(7) for details. The
> >           --namespace command-line option also sets this value.
> >
> >       GIT_CEILING_DIRECTORIES
> >           This should be a colon-separated list of absolute paths. If set, it
> >           is a list of directories that Git should not chdir up into while
> >           looking for a repository directory (useful for excluding
> >           slow-loading network directories). It will not exclude the current
> >           working directory or a GIT_DIR set on the command line or in the
> >           environment. Normally, Git has to read the entries in this list and
> >           resolve any symlink that might be present in order to compare them
> >           with the current directory. However, if even this access is slow,
> >           you can add an empty entry to the list to tell Git that the
> >           subsequent entries are not symlinks and needn't be resolved; e.g.,
> >           GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink.
> >
> >       GIT_DISCOVERY_ACROSS_FILESYSTEM
> >           When run in a directory that does not have ".git" repository
> >           directory, Git tries to find such a directory in the parent
> >           directories to find the top of the working tree, but by default it
> >           does not cross filesystem boundaries. This environment variable can
> >           be set to true to tell Git not to stop at filesystem boundaries.
> >           Like GIT_CEILING_DIRECTORIES, this will not affect an explicit
> >           repository directory set via GIT_DIR or on the command line.
> >
> >       GIT_COMMON_DIR
> >           If this variable is set to a path, non-worktree files that are
> >           normally in $GIT_DIR will be taken from this path instead.
> >           Worktree-specific files such as HEAD or index are taken from
> >           $GIT_DIR. See gitrepository-layout(5) and git-worktree(1) for
> >           details. This variable has lower precedence than other path
> >           variables such as GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY...
> >
> >   Git Commits
> >       GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME,
> >       GIT_COMMITTER_EMAIL, GIT_COMMITTER_DATE, EMAIL
> >           see git-commit-tree(1)
> >
> >   Git Diffs
> >       GIT_DIFF_OPTS
> >           Only valid setting is "--unified=??" or "-u??" to set the number of
> >           context lines shown when a unified diff is created. This takes
> >           precedence over any "-U" or "--unified" option value passed on the
> >           Git diff command line.
> >
> >       GIT_EXTERNAL_DIFF
> >           When the environment variable GIT_EXTERNAL_DIFF is set, the program
> >           named by it is called, instead of the diff invocation described
> >           above. For a path that is added, removed, or modified,
> >           GIT_EXTERNAL_DIFF is called with 7 parameters:
> >
> >               path old-file old-hex old-mode new-file new-hex new-mode
> >
> >           where:
> >
> >       <old|new>-file
> >           are files GIT_EXTERNAL_DIFF can use to read the contents of
> >           <old|new>,
> >
> >       <old|new>-hex
> >           are the 40-hexdigit SHA-1 hashes,
> >
> >       <old|new>-mode
> >           are the octal representation of the file modes.
> >
> >           The file parameters can point at the user's working file (e.g.
> >           new-file in "git-diff-files"), /dev/null (e.g.  old-file when a new
> >           file is added), or a temporary file (e.g.  old-file in the index).
> >           GIT_EXTERNAL_DIFF should not worry about unlinking the temporary
> >           file --- it is removed when GIT_EXTERNAL_DIFF exits.
> >
> >           For a path that is unmerged, GIT_EXTERNAL_DIFF is called with 1
> >           parameter, <path>.
> >
> >           For each path GIT_EXTERNAL_DIFF is called, two environment
> >           variables, GIT_DIFF_PATH_COUNTER and GIT_DIFF_PATH_TOTAL are set.
> >
> >       GIT_DIFF_PATH_COUNTER
> >           A 1-based counter incremented by one for every path.
> >
> >       GIT_DIFF_PATH_TOTAL
> >           The total number of paths.
> >
> >   other
> >       GIT_MERGE_VERBOSITY
> >           A number controlling the amount of output shown by the recursive
> >           merge strategy. Overrides merge.verbosity. See git-merge(1)
> >
> >       GIT_PAGER
> >           This environment variable overrides $PAGER. If it is set to an
> >           empty string or to the value "cat", Git will not launch a pager.
> >           See also the core.pager option in git-config(1).
> >
> >       GIT_EDITOR
> >           This environment variable overrides $EDITOR and $VISUAL. It is used
> >           by several Git commands when, on interactive mode, an editor is to
> >           be launched. See also git-var(1) and the core.editor option in git-
> >           config(1).
> >
> >       GIT_SSH, GIT_SSH_COMMAND
> >           If either of these environment variables is set then git fetch and
> >           git push will use the specified command instead of ssh when they
> >           need to connect to a remote system. The command-line parameters
> >           passed to the configured command are determined by the ssh variant.
> >           See ssh.variant option in git-config(1) for details.
> >
> >       + $GIT_SSH_COMMAND takes precedence over $GIT_SSH, and is interpreted
> >       by the shell, which allows additional arguments to be included.
> >       $GIT_SSH on the other hand must be just the path to a program (which
> >       can be a wrapper shell script, if additional arguments are needed).
> >
> >       + Usually it is easier to configure any desired options through your
> >       personal .ssh/config file. Please consult your ssh documentation for
> >       further details.
> >
> >       GIT_SSH_VARIANT
> >           If this environment variable is set, it overrides Git's
> >           autodetection whether GIT_SSH/GIT_SSH_COMMAND/core.sshCommand refer
> >           to OpenSSH, plink or tortoiseplink. This variable overrides the
> >           config setting ssh.variant that serves the same purpose.
> >
> >       GIT_ASKPASS
> >           If this environment variable is set, then Git commands which need
> >           to acquire passwords or passphrases (e.g. for HTTP or IMAP
> >           authentication) will call this program with a suitable prompt as
> >           command-line argument and read the password from its STDOUT. See
> >           also the core.askPass option in git-config(1).
> >
> >       GIT_TERMINAL_PROMPT
> >           If this environment variable is set to 0, git will not prompt on
> >           the terminal (e.g., when asking for HTTP authentication).
> >
> >       GIT_CONFIG_NOSYSTEM
> >           Whether to skip reading settings from the system-wide
> >           $(prefix)/etc/gitconfig file. This environment variable can be used
> >           along with $HOME and $XDG_CONFIG_HOME to create a predictable
> >           environment for a picky script, or you can set it temporarily to
> >           avoid using a buggy /etc/gitconfig file while waiting for someone
> >           with sufficient permissions to fix it.
> >
> >       GIT_FLUSH
> >           If this environment variable is set to "1", then commands such as
> >           git blame (in incremental mode), git rev-list, git log, git
> >           check-attr and git check-ignore will force a flush of the output
> >           stream after each record have been flushed. If this variable is set
> >           to "0", the output of these commands will be done using completely
> >           buffered I/O. If this environment variable is not set, Git will
> >           choose buffered or record-oriented flushing based on whether stdout
> >           appears to be redirected to a file or not.
> >
> >       GIT_TRACE
> >           Enables general trace messages, e.g. alias expansion, built-in
> >           command execution and external command execution.
> >
> >           If this variable is set to "1", "2" or "true" (comparison is case
> >           insensitive), trace messages will be printed to stderr.
> >
> >           If the variable is set to an integer value greater than 2 and lower
> >           than 10 (strictly) then Git will interpret this value as an open
> >           file descriptor and will try to write the trace messages into this
> >           file descriptor.
> >
> >           Alternatively, if the variable is set to an absolute path (starting
> >           with a / character), Git will interpret this as a file path and
> >           will try to append the trace messages to it.
> >
> >           Unsetting the variable, or setting it to empty, "0" or "false"
> >           (case insensitive) disables trace messages.
> >
> >       GIT_TRACE_FSMONITOR
> >           Enables trace messages for the filesystem monitor extension. See
> >           GIT_TRACE for available trace output options.
> >
> >       GIT_TRACE_PACK_ACCESS
> >           Enables trace messages for all accesses to any packs. For each
> >           access, the pack file name and an offset in the pack is recorded.
> >           This may be helpful for troubleshooting some pack-related
> >           performance problems. See GIT_TRACE for available trace output
> >           options.
> >
> >       GIT_TRACE_PACKET
> >           Enables trace messages for all packets coming in or out of a given
> >           program. This can help with debugging object negotiation or other
> >           protocol issues. Tracing is turned off at a packet starting with
> >           "PACK" (but see GIT_TRACE_PACKFILE below). See GIT_TRACE for
> >           available trace output options.
> >
> >       GIT_TRACE_PACKFILE
> >           Enables tracing of packfiles sent or received by a given program.
> >           Unlike other trace output, this trace is verbatim: no headers, and
> >           no quoting of binary data. You almost certainly want to direct into
> >           a file (e.g., GIT_TRACE_PACKFILE=/tmp/my.pack) rather than
> >           displaying it on the terminal or mixing it with other trace output.
> >
> >           Note that this is currently only implemented for the client side of
> >           clones and fetches.
> >
> >       GIT_TRACE_PERFORMANCE
> >           Enables performance related trace messages, e.g. total execution
> >           time of each Git command. See GIT_TRACE for available trace output
> >           options.
> >
> >       GIT_TRACE_SETUP
> >           Enables trace messages printing the .git, working tree and current
> >           working directory after Git has completed its setup phase. See
> >           GIT_TRACE for available trace output options.
> >
> >       GIT_TRACE_SHALLOW
> >           Enables trace messages that can help debugging fetching / cloning
> >           of shallow repositories. See GIT_TRACE for available trace output
> >           options.
> >
> >       GIT_TRACE_CURL
> >           Enables a curl full trace dump of all incoming and outgoing data,
> >           including descriptive information, of the git transport protocol.
> >           This is similar to doing curl --trace-ascii on the command line.
> >           This option overrides setting the GIT_CURL_VERBOSE environment
> >           variable. See GIT_TRACE for available trace output options.
> >
> >       GIT_TRACE_CURL_NO_DATA
> >           When a curl trace is enabled (see GIT_TRACE_CURL above), do not
> >           dump data (that is, only dump info lines and headers).
> >
> >       GIT_REDACT_COOKIES
> >           This can be set to a comma-separated list of strings. When a curl
> >           trace is enabled (see GIT_TRACE_CURL above), whenever a "Cookies:"
> >           header sent by the client is dumped, values of cookies whose key is
> >           in that list (case-sensitive) are redacted.
> >
> >       GIT_LITERAL_PATHSPECS
> >           Setting this variable to 1 will cause Git to treat all pathspecs
> >           literally, rather than as glob patterns. For example, running
> >           GIT_LITERAL_PATHSPECS=1 git log -- '*.c' will search for commits
> >           that touch the path *.c, not any paths that the glob *.c matches.
> >           You might want this if you are feeding literal paths to Git (e.g.,
> >           paths previously given to you by git ls-tree, --raw diff output,
> >           etc).
> >
> >       GIT_GLOB_PATHSPECS
> >           Setting this variable to 1 will cause Git to treat all pathspecs as
> >           glob patterns (aka "glob" magic).
> >
> >       GIT_NOGLOB_PATHSPECS
> >           Setting this variable to 1 will cause Git to treat all pathspecs as
> >           literal (aka "literal" magic).
> >
> >       GIT_ICASE_PATHSPECS
> >           Setting this variable to 1 will cause Git to treat all pathspecs as
> >           case-insensitive.
> >
> >       GIT_REFLOG_ACTION
> >           When a ref is updated, reflog entries are created to keep track of
> >           the reason why the ref was updated (which is typically the name of
> >           the high-level command that updated the ref), in addition to the
> >           old and new values of the ref. A scripted Porcelain command can use
> >           set_reflog_action helper function in git-sh-setup to set its name
> >           to this variable when it is invoked as the top level command by the
> >           end user, to be recorded in the body of the reflog.
> >
> >       GIT_REF_PARANOIA
> >           If set to 1, include broken or badly named refs when iterating over
> >           lists of refs. In a normal, non-corrupted repository, this does
> >           nothing. However, enabling it may help git to detect and abort some
> >           operations in the presence of broken refs. Git sets this variable
> >           automatically when performing destructive operations like git-
> >           prune(1). You should not need to set it yourself unless you want to
> >           be paranoid about making sure an operation has touched every ref
> >           (e.g., because you are cloning a repository to make a backup).
> >
> >       GIT_ALLOW_PROTOCOL
> >           If set to a colon-separated list of protocols, behave as if
> >           protocol.allow is set to never, and each of the listed protocols
> >           has protocol.<name>.allow set to always (overriding any existing
> >           configuration). In other words, any protocol not mentioned will be
> >           disallowed (i.e., this is a whitelist, not a blacklist). See the
> >           description of protocol.allow in git-config(1) for more details.
> >
> >       GIT_PROTOCOL_FROM_USER
> >           Set to 0 to prevent protocols used by fetch/push/clone which are
> >           configured to the user state. This is useful to restrict recursive
> >           submodule initialization from an untrusted repository or for
> >           programs which feed potentially-untrusted URLS to git commands. See
> >           git-config(1) for more details.
> >
> >       GIT_PROTOCOL
> >           For internal use only. Used in handshaking the wire protocol.
> >           Contains a colon : separated list of keys with optional values
> >           key[=value]. Presence of unknown keys and values must be ignored.
> >
> >       GIT_OPTIONAL_LOCKS
> >           If set to 0, Git will complete any requested operation without
> >           performing any optional sub-operations that require taking a lock.
> >           For example, this will prevent git status from refreshing the index
> >           as a side effect. This is useful for processes running in the
> >           background which do not want to cause lock contention with other
> >           operations on the repository. Defaults to 1.
> >
> >       GIT_REDIRECT_STDIN, GIT_REDIRECT_STDOUT, GIT_REDIRECT_STDERR
> >           Windows-only: allow redirecting the standard input/output/error
> >           handles to paths specified by the environment variables. This is
> >           particularly useful in multi-threaded applications where the
> >           canonical way to pass standard handles via CreateProcess() is not
> >           an option because it would require the handles to be marked
> >           inheritable (and consequently every spawned process would inherit
> >           them, possibly blocking regular Git operations). The primary
> >           intended use case is to use named pipes for communication (e.g.
> >           \\.\pipe\my-git-stdin-123).
> >
> >           Two special values are supported: off will simply close the
> >           corresponding standard handle, and if GIT_REDIRECT_STDERR is 2>&1,
> >           standard error will be redirected to the same handle as standard
> >           output.
> >
> >       GIT_PRINT_SHA1_ELLIPSIS (deprecated)
> >           If set to yes, print an ellipsis following an (abbreviated) SHA-1
> >           value. This affects indications of detached HEADs (git-checkout(1))
> >           and the raw diff output (git-diff(1)). Printing an ellipsis in the
> >           cases mentioned is no longer considered adequate and support for it
> >           is likely to be removed in the foreseeable future (along with the
> >           variable).
> >
> >DISCUSSION
> >       More detail on the following is available from the Git concepts chapter
> >       of the user-manual[2] and gitcore-tutorial(7).
> >
> >       A Git project normally consists of a working directory with a ".git"
> >       subdirectory at the top level. The .git directory contains, among other
> >       things, a compressed object database representing the complete history
> >       of the project, an "index" file which links that history to the current
> >       contents of the working tree, and named pointers into that history such
> >       as tags and branch heads.
> >
> >       The object database contains objects of three main types: blobs, which
> >       hold file data; trees, which point to blobs and other trees to build up
> >       directory hierarchies; and commits, which each reference a single tree
> >       and some number of parent commits.
> >
> >       The commit, equivalent to what other systems call a "changeset" or
> >       "version", represents a step in the project's history, and each parent
> >       represents an immediately preceding step. Commits with more than one
> >       parent represent merges of independent lines of development.
> >
> >       All objects are named by the SHA-1 hash of their contents, normally
> >       written as a string of 40 hex digits. Such names are globally unique.
> >       The entire history leading up to a commit can be vouched for by signing
> >       just that commit. A fourth object type, the tag, is provided for this
> >       purpose.
> >
> >       When first created, objects are stored in individual files, but for
> >       efficiency may later be compressed together into "pack files".
> >
> >       Named pointers called refs mark interesting points in history. A ref
> >       may contain the SHA-1 name of an object or the name of another ref.
> >       Refs with names beginning ref/head/ contain the SHA-1 name of the most
> >       recent commit (or "head") of a branch under development. SHA-1 names of
> >       tags of interest are stored under ref/tags/. A special ref named HEAD
> >       contains the name of the currently checked-out branch.
> >
> >       The index file is initialized with a list of all paths and, for each
> >       path, a blob object and a set of attributes. The blob object represents
> >       the contents of the file as of the head of the current branch. The
> >       attributes (last modified time, size, etc.) are taken from the
> >       corresponding file in the working tree. Subsequent changes to the
> >       working tree can be found by comparing these attributes. The index may
> >       be updated with new content, and new commits may be created from the
> >       content stored in the index.
> >
> >       The index is also capable of storing multiple entries (called "stages")
> >       for a given pathname. These stages are used to hold the various
> >       unmerged version of a file when a merge is in progress.
> >
> >FURTHER DOCUMENTATION
> >       See the references in the "description" section to get started using
> >       Git. The following is probably more detail than necessary for a
> >       first-time user.
> >
> >       The Git concepts chapter of the user-manual[2] and gitcore-tutorial(7)
> >       both provide introductions to the underlying Git architecture.
> >
> >       See gitworkflows(7) for an overview of recommended workflows.
> >
> >       See also the howto[3] documents for some useful examples.
> >
> >       The internals are documented in the Git API documentation[4].
> >
> >       Users migrating from CVS may also want to read gitcvs-migration(7).
> >
> >AUTHORS
> >       Git was started by Linus Torvalds, and is currently maintained by Junio
> >       C Hamano. Numerous contributions have come from the Git mailing list
> >       <git@vger.kernel.org[5]>.
> >       http://www.openhub.net/p/git/contributors/summary gives you a more
> >       complete list of contributors.
> >
> >       If you have a clone of git.git itself, the output of git-shortlog(1)
> >       and git-blame(1) can show you the authors for specific parts of the
> >       project.
> >
> >REPORTING BUGS
> >       Report bugs to the Git mailing list <git@vger.kernel.org[5]> where the
> >       development and maintenance is primarily done. You do not have to be
> >       subscribed to the list to send a message there. See the list archive at
> >       https://public-inbox.org/git for previous bug reports and other
> >       discussions.
> >
> >       Issues which are security relevant should be disclosed privately to the
> >       Git Security mailing list <git-security@googlegroups.com[6]>.
> >
> >SEE ALSO
> >       gittutorial(7), gittutorial-2(7), giteveryday(7), gitcvs-migration(7),
> >       gitglossary(7), gitcore-tutorial(7), gitcli(7), The Git User's
> >       Manual[1], gitworkflows(7)
> >
> >GIT
> >       Part of the git(1) suite
> >
> >NOTES
> >        1. Git User's Manual
> >           file:///home/frederik/share/doc/git-doc/user-manual.html
> >
> >        2. Git concepts chapter of the user-manual
> >           file:///home/frederik/share/doc/git-doc/user-manual.html#git-concepts
> >
> >        3. howto
> >           file:///home/frederik/share/doc/git-doc/howto-index.html
> >
> >        4. Git API documentation
> >           file:///home/frederik/share/doc/git-doc/technical/api-index.html
> >
> >        5. git@vger.kernel.org
> >           mailto:git@vger.kernel.org
> >
> >        6. git-security@googlegroups.com
> >           mailto:git-security@googlegroups.com
> >
> >Git 2.21.0.rc1.9.g3f              02/18/2019                            GIT(1)
>

  reply	other threads:[~2019-03-11 14:38 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
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 [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to='CA+P7+xpC5mDRx1ev-3ebGMEexgvLv-kDtM=9g35hRETOPo6c8g@mail.gmail.com' \
    --to=jacob.keller@gmail.com \
    --cc=frederik@ofb.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=sunshine@sunshineco.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git