fetch doc: update introductory part for clarity

 - "Branches" is a more common way to say "heads" in these days.

 - Remote-tracking branches are used a lot more these days and it is
   worth mentioning that it is one of the primary side effects of
   the command to update them.

 - Avoid "X. That means Y."  If Y is easier to understand to
   readers, just say that upfront.

 - Use of explicit refspec to fetch tags does not have much to do
   with turning "auto following" on or off.  It is a way to fetch
   tags that otherwise would not be fetched by auto-following.

Helped-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch doc: move FETCH_HEAD material lower and add an example

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch doc: update note on '+' in front of the refspec

While it is not *wrong* per-se to say that pulling a rewound/rebased
branch will lead to an unnecessary merge conflict, that is not what
the leading "+" sign to allow non-fast-forward update of remote-tracking
branch is at all.

Helped-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch doc: remove notes on outdated "mixed layout"

In old days before Git 1.5, it was customery for "git fetch" to use
the same local branch namespace to keep track of the remote-tracking
branches, and it was necessary to tell users not to check them out
and commit on them.  Since everybody uses the separate remote layout
these days, there is no need to warn against the practice to check
out the right-hand side of <refspec> and build on it---the RHS is
typically not even a local branch.

Incidentally, this also kills one mention of "Pull:" line of
$GIT_DIR/remotes/* configuration, which is a lot less familiar to
new people than the more modern remote.*.fetch configuration
variable.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch doc: on pulling multiple refspecs

Replace desription of old-style "Pull:" lines in remotes/
configuration with modern remote.*.fetch variables.

As this note applies only to "git pull", enable it only
in git-pull manual page.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch doc: update refspec format description

The text made it sound as if the leading plus is the only thing that
is optional, and forgot that <lhs> is the same as <lhs>:, i.e. fetch
it and do not store anywhere.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch doc: remove "short-cut" section

It is misleading to mention that <ref> that does not store is to
fetch the ref into FETCH_HEAD, because a refspec that does store is
also to fetch the LHS into FETCH_HEAD.  It is doubly misleading to
list it as part of "short-cut".  <ref> stands for a refspec that has
it on the LHS with a colon and an empty RHS, and that definition
should be given at the beginning of the entry where the format is
defined.

Tentatively remove this misleading description, which leaves the
`tag <tag>` as the only true short-hand, so move it at the beginning
of the entry.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch doc: add a section on configured remote-tracking branches

To resurrect a misleading mention removed in the previous step,
add a section to explain how the remote-tracking configuration
interacts with the refspecs given as the command-line arguments.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch: allow explicit --refmap to override configuration

Since the introduction of opportunisitic updates of remote-tracking
branches, started at around f2690487 (fetch: opportunistically
update tracking refs, 2013-05-11) with a few updates in v1.8.4 era,
the remote.*.fetch configuration always kicks in even when a refspec
to specify what to fetch is given on the command line, and there is
no way to disable or override it per-invocation.

Teach the command to pay attention to the --refmap=<lhs>:<rhs>
command-line options that can be used to override the use of
configured remote.*.fetch as the refmap.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t5551: fix the 50,000 tag test

The first version of test 23 did simply check that no output was
sent to the standard error stream.  With 5e2c7cd2 (t5551: do not use
unportable sed '\+', 2013-05-12), we started to also verify that the
expected tags were actually cloned.

Since 68b939b2 (clone: send diagnostic messages to stderr,
2013-09-18), "git clone" shows "Cloning into 'too-many-refs'" to the
standard error stream (it used to do so to the standard output),
causing the test to fail.

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test: turn EXPENSIVE into a lazy prerequisite

Two test scripts (t0021 and t5551) had copy & paste code to set
EXPENSIVE prerequisite.  Use the test_lazy_prereq helper to define
them in the common t/test-lib.sh.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
test: turn USR_BIN_TIME into a lazy prerequisite

Two test scripts (t3302 and t3419) had copy & paste code to set
USR_BIN_TIME prerequisite.  Use the test_lazy_prereq helper to define
them in the common t/test-lib.sh.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
t3302: coding style updates

Use "<<-END_OF_HERE_TEXT" to push the contents of here-text to the
right in order to show the loop structure better.

Use write_script when writing a script to be run.

Use "test" (not "[ ... ]") and avoid unnecessary ";" in the middle
of a line.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
t3302: do not chdir around in the primary test process

These days^Wyears we strive to do stuff in subdirectories inside
subshells to avoid mistakes.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
t3302: drop unnecessary NOT_EXPENSIVE pseudo-prerequisite

This was only necessary because do_tests helper the script defines
took its parameters in a wrong order.  Just pass an empty string (or
not passing the optional EXPENSIVE prerequisite) when running the
test with a light-weight set of parameters and have the shell do the
right thing when parsing test_expect_success helper.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
t3419: drop unnecessary NOT_EXPENSIVE pseudo-prerequisite

This was only necessary because do_tests helper the script defines
took its parameters in a wrong order.  Just pass an empty string (or
not passing the optional EXPENSIVE prerequisite) when running the
test with a light-weight set of parameters and have the shell do the
right thing when parsing test_expect_success helper.

Also update coding style while we are at it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use starts_with() for C strings instead of memcmp()

Convert three cases of checking for a constant prefix using memcmp() to
starts_with().  This way there is no need for magic string length
constants and we avoid running over the end of the string should it be
shorter than the prefix.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
revision: parse "git log -<count>" more carefully

This mistyped command line simply ignores "master" and ends up
showing two commits from the current HEAD:

    $ git log -2master

because we feed "2master" to atoi() without making sure that the
whole string is parsed as an integer.

Use the strtol_i() helper function instead.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
api-strbuf.txt minor typos

Fixed some minor typos in api-strbuf.txt: 'A' instead of 'An', 'have'
instead of 'has', a overlong line, and 'another' instead of 'an other'.

Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t9001: avoid non-portable '\n' with sed

t9001 used a '\n' in a sed expression to split one line into two
lines, but the usage of '\n' in the "replacement string" is not
portable.

The '\n' can be used to match a newline in the "pattern space",
but otherwise the meaning of '\n' is unspecified in POSIX.

- Gnu versions of sed will treat '\n' as a newline character.
- Other versions of sed (like /usr/bin/sed under Mac OS X)
  simply ignore the '\' before the 'n', treating '\n' as 'n'.

For reference see:
pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html
http://www.gnu.org/software/sed/manual/sed.html

As the test already requires perl as a prerequisite, use perl
instead of sed.

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>