When we refuse to make an empty commit, we check whether we
are in a cherry-pick in order to give better advice on how
to proceed. We instruct the user to repeat the commit with
"--allow-empty" to force the commit, or to use "git reset"
to skip it and abort the cherry-pick.

In the case of a single cherry-pick, the distinction between
skipping and aborting is not important, as there is no more
work to be done afterwards.  When we are using the sequencer
to cherry pick a series of commits, though, the instruction
is confusing: does it skip this commit, or does it abort the
rest of the cherry-pick?

It does skip, after which the user can continue the
cherry-pick. This is the right thing to be advising the user
to do, but let's make it more clear what will happen, both
by using the word "skip", and by mentioning that the rest of
the sequence can be continued via "cherry-pick --continue"
(whether we skip or take the commit).
Noticed-by: NRamkumar Ramachandra <artagnon@gmail.com>
Helped-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We earlier removed a link to list of contributors that pointed to a
defunct page; let's use a working one from Ohloh.net to replace it
instead.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* sl/maint-git-svn-docs:
  git-svn: Note about tags.
  git-svn: Expand documentation for --follow-parent
  git-svn: Recommend use of structure options.
  git-svn: Document branches with at-sign(@).

Document that 'git svn' will import SVN tags as branches.
Signed-off-by: NSebastian Leske <sebastian.leske@sleske.name>
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Describe what the option --follow-parent does, and what happens if it is
set or unset.
Signed-off-by: NSebastian Leske <sebastian.leske@sleske.name>
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Document that when using git svn, one should usually either use the
directory structure options to import branches as branches, or only
import one subdirectory. The default behaviour of cloning all branches
and tags as subdirectories in the working copy is usually not what the
user wants.
Signed-off-by: NSebastian Leske <sebastian.leske@sleske.name>
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git svn sometimes creates branches with an at-sign in the name
(branchname@revision). These branches confuse many users and it is a FAQ
why they are created. Document when git svn creates them.
Signed-off-by: NSebastian Leske <sebastian.leske@sleske.name>
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* branch 'gb/maint-doc-svn-log-window-size':
  Document git-svn fetch --log-window-size parameter

* branch 'km/maint-doc-git-reset':
  doc: git-reset: make "<mode>" optional

In the distant past, the order things were documented was
'Invocation', 'Commands', 'Capabilities', ...

Then it was decided that before giving a list of Commands, there
should be an overall description of the 'Input format', which was
a wise decision. However, this description was put as the very
first thing, with the rationale that any implementor would want
to know that first.

However, it seems an implementor would actually first need to
know how the remote helper will be invoked, so moving
'Invocation' to the front again seems logical. Moreover, we now
don't switch from discussing the input format to the invocation
style and then back to input related stuff.
Signed-off-by: NMax Horn <max@quendi.de>
Acked-by: NSverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* jk/avoid-mailto-invalid-in-doc:
  Documentation: don't link to example mail addresses

* branch 'tj/maint-doc-commit-sign':
  Add -S, --gpg-sign option to manpage of "git commit"

19299a84 (Documentation: Move diff.<driver>.* from config.txt to
diff-config.txt, 2011-04-07) moved the diff configuration options to
diff-config.txt, but forgot about diff.wordRegex, which was left
behind in config.txt.  Fix this.
Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com>
Acked-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* jc/doc-diff-blobs:
  Documentation: Describe "git diff <blob> <blob>" separately

* cr/doc-checkout-branch:
  Documentation/git-checkout.txt: document 70c9ac2f behavior
  Documentation/git-checkout.txt: clarify usage

* ta/api-index-doc:
  Remove misleading date from api-index-skel.txt

* as/doc-for-devs:
  Documentation: move support for old compilers to CodingGuidelines
  SubmittingPatches: add convention of prefixing commit messages

* sl/readme-gplv2:
  README: it does not matter who the current maintainer is
  README: Git is released under the GPLv2, not just "the GPL"

* jc/fetch-tags-doc:
  fetch --tags: clarify documentation

* nd/index-format-doc:
  index-format.txt: clarify what is "invalid"

* jk/mailmap-cleanup:
  contrib: update stats/mailmap script
  .mailmap: normalize emails for Linus Torvalds
  .mailmap: normalize emails for Jeff King
  .mailmap: fix broken entry for Martin Langhoff
  .mailmap: match up some obvious names/emails

* ta/doc-cleanup:
  Documentation: build html for all files in technical and howto
  Documentation/howto: convert plain text files to asciidoc
  Documentation/technical: convert plain text files to asciidoc
  Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
  Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
  Split over-long synopsis in git-fetch-pack.txt into several lines

Howto documents in howto-index.txt were listed in a rather
random order. So better sort them.
Signed-off-by: NThomas Ackermann <th.acker@arcor.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

As it was not a common operation, it was described as if it is a
side note for the more common two-commit variant, but this mode
behaves very differently, e.g. it does not make any sense to ask
recursive behaviour, or give the command a pathspec.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

These tests themselves are properly protected by the GPG
prerequisite, but one of the set-up steps outside the
test_expect_success block unconditionally assumed that there is a
gpghome/ directory, which is not true if GPG is not being used.

It may be a good idea to move the whole set-up steps in the test but
that is a follow-up topic.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Document the behavior implemented in 70c9ac2f (DWIM "git checkout
frotz" to "git checkout -b frotz origin/frotz").
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The forms of checkout that do not take a path are lumped together in
the DESCRIPTION section, but the description for this group is
dominated by explanation of the -b|-B form.

Split these apart for more clarity.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

"git log -p -S<string>" now looks for the <string> after applying
the textconv filter (if defined); earlier it inspected the contents
of the blobs without filtering.

Signed-off-by: NSitaram Chamarty <sitaramc@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The "Try to be nice to older C compilers" text is clearly a guideline
to be borne in mind whilst coding rather than when submitting patches.
Signed-off-by: NAdam Spiers <git@adamspiers.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Conscientious newcomers to git development will read SubmittingPatches
and CodingGuidelines, but could easily miss the convention of
prefixing commit messages with a single word identifying the file
or area the commit touches.
Signed-off-by: NAdam Spiers <git@adamspiers.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Email addresses in documentation are converted into mailto: hyperlinks
in the HTML output and footnotes in man pages.  This isn't desirable for
cases where the address is used as an example and is not valid.

Particularly annoying is the example "jane@laptop.(none)" which appears
in git-shortlog(1) as "jane@laptop[1].(none)", with note 1 saying:

	1. jane@laptop
	   mailto:jane@laptop

Fix this by escaping these email addresses with a leading backslash, to
prevent Asciidoc expanding them as inline macros.

In the case of mailmap.txt, render the address monospaced so that it
matches the block examples surrounding that paragraph.
Helped-by: NJeff King <peff@peff.net>
Signed-off-by: NJohn Keeping <john@keeping.me.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NThomas Ackermann <th.acker@arcor.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The audience of this introductory document does not have to know nor
interact with the maintainer, so drop the mention of him.  Other
documents such as SubmittingPatches may be a more suitable place to
have it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

And this is clearly stressed by Linus in the COPYING file.  So make it
clear in the README as well, to avoid possible misunderstandings.
Signed-off-by: NStefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Explain that --tags is just like another explicit refspec on the
command line and as such overrides the default refspecs configured
via the remote.$name.fetch variable.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently it gets the size of an otherwise unrelated, unused variable
instead of the expected struct size.
Signed-off-by: NMatthew Daley <mattjd@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Unlike other environment variables (e.g. GIT_WORK_TREE,	GIT_NAMESPACE),
the Documentation/git.txt file did not mention that the GIT_DIR
environment variable can also be set using the --git-dir command line
option.
Signed-off-by: NManlio Perillo <manlio.perillo@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

A cache-tree entry with a negative entry count is considered invalid
by the current Git; it records that we do not know the object name
of a tree that would result by writing the directory covered by the
cache-tree as a tree object.

Clarify that any entry with a negative entry count is invalid, but
the implementations must write -1 there. This way, we can later
decide to allow writers to use negative values other than -1 to
encode optional information on such invalidated entries without
harming interoperability; we do not know what will be encoded and
how, so we keep these other negative values as reserved for now.
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>