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 [thread overview]
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)
>
next prev parent 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
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
https://80x24.org/mirrors/git.git
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).