doc/clone: Remove the '--bare -l -s' example

There are other examples in git-clone.txt demonstrating both '--bare'
and '-l -s'.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
doc/clone: Pick more compelling paths for the --reference example

There may be times when using one of your local repositories as a
reference for a new clone make sense, but the implied version-bump in
the old example isn't one of them.  I think a more intuitive example
is multi-user system with a central reference clone, and the new paths
hint at this use case.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: Update the NFS remote examples to use the staging repo

linux-nfs.org seems to have restructured their repository layout since
8391c60 (git-remote.txt: fix example url, 2007-11-02), and Bruce's
repo is now at git://git.linux-nfs.org/projects/bfields/linux.git.
Bruce also has a more richer internal branch structure (master,
everything, for-3.1, ...), so updating the existing example to use his
current repo may be confusing.

To simplify, I've replaced the NFS repo with Greg's staging repo.
I've also updated the output of the surrounding commands to match the
output of a current run through.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: Update 'linux-2.6.git' -> 'linux.git'

The 3.x tree has been out for a while now.  The -2.6 repository name
survived the initial release [1], but kernel.org now only lists
'linux.git' (for aegl as well as torvalds) [2].

[1]: http://article.gmane.org/gmane.linux.kernel/1147422
  On 2011-05-30 01:47:57 GMT, Linus Torvalds wrote:
  > ... yes, that means that my git tree is still called
  > "linux-2.6.git" on kernel.org.
[2]: http://git.kernel.org/cgit/

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t5505-remote: modernize style

Modernize the style of all tests throughout the file:

 - Remove spurious blank lines.

 - Indent the test body.

 - Make sure that all lines end with &&, to make it easier to spot
   breaks in the chain.

 - When executing something in a subshell, put the parenthesis on
   separate lines and indent the body.  Also make sure that the
   first statement in the subshell is a 'cd'.

 - When redirecting input or output, do not use SP between
   redirection operator and the target filename.

 - Use the <<-\EOF and <<-EOF forms of heredoc, not <<EOF, when the
   command is indented and the heredoc text itself does not have to
   have a leading tab.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t5505-remote: test push-refspec in branches-file

The test "migrate a remote from named file in $GIT_DIR/branches" reads
the branches-file, but only checks that the url and fetch-refspec are
set correctly.  Check that the push-refspec is also set correctly.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t5505-remote: use test_path_is_missing

Replace instances of ! test -f with test_path_is_missing.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote: remove dead code in read_branches_file()

The first line of the function checks that the remote-name contains a
slash ('/'), and sets the "slash" variable accordingly.  The only caller
of read_branches_file() is remote_get_1(); the calling codepath is
guarded by valid_remote_nick(), which checks that the remote does not
contain a slash.  Therefore, the "slash" variable can never be set:
remove the dead code that assumes otherwise.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t5505-remote: test url-with-# in branches-file

Add one more test similar to "migrate a remote from named file in
$GIT_DIR/branches" to check that a url with a # can be used to specify
the branch name (as opposed to the constant "master").

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ls-remote doc: fix example invocation on git.git

Under the EXAMPLES section, there is one invocation on the git.git
repository that attempts to list the refs master, pu, and rc.  The ref
rc does not exist in today's repository, so remove it.  Among other
things, this example demonstrates that the "<refs>..." argument is
simply a filter; requesting a non-existent ref is not an error.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ls-remote doc: rewrite <repository> paragraph

Replace the <repository> paragraph containing specific references to
$GIT_DIR/branches and "." with a generic urls-or-remotes paragraph
referencing the relevant sections in the git-fetch(1) manpage.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ls-remote doc: don't encourage use of branches-file

One outdated example encourages the use of $GIT_DIR/branches files.
Replace it with an equivalent example using a remote.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t5505-remote: test multiple push/pull in remotes-file

Extend the test "migrate a remote from named file in $GIT_DIR/remotes"
to test that multiple "Push:" and "Pull:" lines in the remotes-file
works as expected.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-lib: self-test that --verbose works

t0000 contains some light self-tests of test-lib.sh, but --verbose was
not covered.  Add a test.

The only catch is that the presence of a test harness influences the
output (specifically, the presence of some empty lines).  So we need
to unset TEST_HARNESS or set it to a known value.  Leaving it unset
leads to spurious test failures in the final summary, which come from
the subtest.  So we always set it.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-lib: verbose mode for only tests matching a pattern

With the new --verbose-only=<pattern> option, one can enable --verbose
at a per-test granularity.  The pattern is matched against the test
number, e.g.

  ./t0000-basic.sh --verbose-only='2[0-2]'

to see only the full output of test 20-22, while showing the rest in the
one-liner format.

As suggested by Jeff King, this takes care to wrap the entire
test_expect_* block, but nothing else, in the verbose toggling.  We
can use the test_start/end functions from the previous commit for the
purpose.

This is arguably not *too* useful on its own, but makes the next patch
easier to follow.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-lib: valgrind for only tests matching a pattern

With the new --valgrind-only=<pattern> option, one can enable
--valgrind at a per-test granularity, exactly analogous to
--verbose-only from the previous commit.

The options are wired such that --valgrind implies --verbose (as
before), but --valgrind-only=<pattern> implies
--verbose-only=<pattern> unless --verbose is also in effect.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-lib: allow prefixing a custom string before "ok N" etc.

This is not really meant for external use, and thus not documented. It
allows the next commit to neatly distinguish between sub-tests and the
main run.

The format is intentionally not valid TAP.  The use in the next commit
would not result in anything valid either way, and it seems better to
make it obvious.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-lib: support running tests under valgrind in parallel

With the new --valgrind-parallel=<n> option, we support running the
tests in a single test script under valgrind in parallel using 'n'
processes.

This really follows the dumbest approach possible, as follows:

* We spawn the test script 'n' times, using a throw-away
  TEST_OUTPUT_DIRECTORY.  Each of the instances is given options that
  ensures that it only runs every n-th test under valgrind, but
  together they cover the entire range.

* We add up the numbers from the individual tests, and provide the
  usual output.

This is really a gross hack at this point, and should be improved.  In
particular we should keep the actual outputs somewhere more easily
discoverable, and summarize them to the user.

Nevertheless, this is already workable and gives a speedup of more
than 2 on a dual-core (hyperthreaded) machine, using n=4.  This is
expected since the overhead of valgrind is so big (on the order of 20x
under good conditions, and a large startup overhead at every git
invocation) that redundantly running the non-valgrind tests in between
is not that expensive.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
add -i: add extra options at the right place in "diff" command line

Appending "--diff-algorithm=histogram" at the end of canned command
line for various modes of "diff" is correct for most of them but not
for "stash" that has a non-option already wired in, like so:

	'stash' => {
		DIFF => 'diff-index -p HEAD',

Appending an extra option after non-option may happen to work due to
overly lax command line parser, but that is not something we should
rely on.  Instead, splice in the extra argument immediately after the
command name (i.e. 'diff-index', 'diff-files', etc.).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jk/commit-info-slab' into jch

Allow adding custom information to commit objects in order to
represent unbound number of flag bits etc.

* jk/commit-info-slab:
  commit-slab: introduce a macro to define a slab for new type
  commit-slab: avoid large realloc
  commit: allow associating auxiliary info on-demand