* maint-1.7.11:
Prepare for 1.7.11.6
Make the ciabot scripts completely self-configuring in the normal case.
Improved documentation for the ciabot scripts.
man: git pull -r is a short for --rebase
gitcli: describe abbreviation of long options
rev-list docs: clarify --topo-order description
Documentation/CodingGuidelines: spell out more shell guidelines
Documentation: do not mention .git/refs/* directories
tests: Introduce test_seq
We did not document that many commands take unique prefix
abbreviations of long options (e.g. "--option" may be the only flag
that the command accepts that begin with "--opt", in which case you
can give "--opt") anywhere easy to find for new people.
* jc/maint-abbrev-option-cli:
gitcli: describe abbreviation of long options
It was unclear what "--topo-order" was really about in the
documentation. It is not just about "children before parent", but
also about "don't mix lineages".
* jc/maint-rev-list-topo-doc:
rev-list docs: clarify --topo-order description
In earlier days, "imitate the style in the neibouring code" was
sufficient to keep the coherent style, but over time some parts of
the codebase have drifted enough to make it ineffective.
* hv/coding-guidelines:
Documentation/CodingGuidelines: spell out more shell guidelines
Our documentation used to assume having files in .git/refs/*
directories was the only to have branches and tags, but that is not
true for quite some time.
* jc/tag-doc:
Documentation: do not mention .git/refs/* directories
The one at kernel.org has not been updated for quite a while and
can no longer be called "the latest".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Letting the "--rebase" option squat on the short-and-sweet single
letter option "-r" was an unintended accident and was not even
documented, but the short option seems to be already used in the
wild. Let's document it so that other options that begin with "r"
would not be tempted to steal it.
Signed-off-by: Miklos Vajna <vmiklos@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was unclear what "--topo-order" was really about in the
documentation. It is not just about "children before parent", but
also about "don't mix lineages".
Reword the description for both "--date-order" and "--topo-order",
and add an illustration to it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In earlier days, "imitate the style in the neibouring code" was
sufficient to keep the coherent style, but over time some parts of
the codebase have drifted enough to make it ineffective.
Spell some of the guidelines out.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit e30b2feb1b (Jun 24 2012, add 'git credential' plumbing command)
forgot to add git-credential to command-list.txt, hence the command was
not appearing in the documentation, making it hard for users to discover
it.
While we're there, capitalize the description line for git-crendential
for consistency with other commands.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
- (glossary) the quotes around the Wikipedia URL prevented its
linkification in frontends that support it; remove them
- (manual) newer version (SHA-1) == following, older == preceding, not
the other way around
- trivial typo and wording fixes
Signed-off-by: Štěpán Němec <stepnem@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is an implementation detail that a new tag is created by adding a
file in the .git/refs/tags directory. The only thing the user needs
to know is that a "git tag" creates a ref in the refs/tags namespace,
and without "-f", it does not overwrite an existing tag.
Inspired by a report from 乙酸鋰 <ch3cooli@gmail.com>; I think I
caught all the existing mention in Documentation/ directory in the
tip of 1.7.9.X maintenance track, but we may have added new ones
since then.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"$GIT_DIR/COMMIT_EDITMSG" file that is used to hold the commit log
message user edits was not documented.
* jk/maint-commit-document-editmsg:
commit: document the temporary commit message file
"git commit-tree" learned a more natural "-p <parent> <tree>" order
of arguments long time ago, but recently forgot it by mistake.
* kk/maint-commit-tree:
Revert "git-commit-tree(1): update synopsis"
commit-tree: resurrect command line parsing updates
When "git am" failed, old timers knew to check .git/rebase-apply/patch
to see what went wrong, but we never told the users about it.
* pg/maint-1.7.9-am-where-is-patch:
am: indicate where a failed patch is to be found
It was a bit hard to learn how <rev>^@, <rev>^! and various other
forms of range specifiers are used, because they were discussed
mostly in the prose part of the documentation, unlike various forms
of extended SHA-1 expressions that are listed in an enumerated list.
Also add a few more examples showing use of <rev>, <rev>..<rev> and
<rev>^! forms, stolen from a patch by Max Horn.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git mergetool" did not support --tool-help option to give the list
of supported backends, like "git difftool" does.
* jc/mergetool-tool-help:
mergetool: support --tool-help option like difftool does
We do not document COMMIT_EDITMSG at all, but users may want
to know about it for two reasons:
1. They may want to tell their editor to configure itself
for formatting a commit message.
2. If a commit is aborted by an error, the user may want
to recover the commit message they typed.
Let's put a note in git-commit(1).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This way we do not have to risk the list of tools going out of sync
between the implementation and the documentation.
In the same spirit as bf73fc2 (difftool: print list of valid tools
with '--tool-help', 2012-03-29), trim the list of merge backends in
the documentation. We do not want to have a complete list of valid
tools; we only want a list to help people guess what kind of things
the tools do to be specified there, and refer them to --tool-help
for a complete list.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git am" failed, old timers knew to check .git/rebase-apply/patch
to see what went wrong, but we never told the users about it.
* pg/maint-1.7.9-am-where-is-patch:
am: indicate where a failed patch is to be found
