user/sven/git.git/Documentation/git-commit.txt, branch v1.7.3.5

git-commit.txt: (synopsis): move -i and -o before "--"

2010-12-01T19:26:43Z

All options, including -i and -o, must come before "--" which is the end of options marker. Reported-by: Joey Hess Signed-off-by: Jari Aalto Signed-off-by: Junio C Hamano

Documentation: spelling fixes

2010-07-20T23:59:17Z

[jc: with wording changes from Jonathan Nieder] Signed-off-by: Junio C Hamano

Merge branch 'maint'

2010-06-07T22:46:01Z

* maint: commit.txt: clarify how --author argument is used

commit.txt: clarify how --author argument is used

2010-06-07T05:13:51Z

commit --author was added by 146ea06 (git commit --author=$name: look $name up in existing commits), but its documentation was sorely lacking compared to its excellent commit message. This commit tries to improve the documentation. Signed-off-by: Jay Soffian Signed-off-by: Junio C Hamano

Add option to git-commit to allow empty log messages

2010-04-07T22:22:57Z

Change git-commit(1) to accept the --allow-empty-message option to allow a commit with an empty message. This is analogous to the existing --allow-empty option which allows a commit that records no changes. As these are mainly for interoperating with foreign SCM systems, and are not meant for normal use, ensure that "git commit -h" does not talk about them. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Documentation: Fix indentation problem in git-commit(1)

2010-02-20T03:03:24Z

Ever since the "See linkgit:git-config[1]..." paragraph was added to the description for --untracked-files (d6293d1), the paragraphs for the following options were indented at the same level as the "See linkgit:git-config[1]" paragraph. This problem showed up in the manpages, but not in the HTML documentation. While this does fix the alignment of the options following --untracked-files in the manpage, the "See linkgit..." portion of the description does not retain its previous indentation level in the manpages, or HTML documentation. Signed-off-by: Jacob Helwig Acked-by: Thomas Rast Signed-off-by: Junio C Hamano

Merge remote branch 'remotes/trast-doc/for-next'

2010-01-21T04:28:49Z

* remotes/trast-doc/for-next: Documentation: spell 'git cmd' without dash throughout Documentation: format full commands in typewriter font Documentation: warn prominently against merging with dirty trees Documentation/git-merge: reword references to "remote" and "pull" Conflicts: Documentation/config.txt Documentation/git-config.txt Documentation/git-merge.txt

Merge branch 'jh/commit-status'

2010-01-18T00:00:07Z

* jh/commit-status: t7502: test commit.status, --status and --no-status commit: support commit.status, --status, and --no-status Conflicts: Documentation/git-commit.txt builtin-commit.c

commit: support commit.status, --status, and --no-status

2010-01-13T08:01:53Z

A new configuration variable commit.status, and new command line options --status, and --no-status control whether or not the git status information is included in the commit message template when using an editor to prepare the commit message. It does not affect the effects of a user's commit.template settings. Signed-off-by: James P. Howard, II Signed-off-by: Junio C Hamano

Documentation: spell 'git cmd' without dash throughout

2010-01-10T12:01:28Z

The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in 647ac70 (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.