t1300: style updates

The t1300 test script is quite old, and does not use our
modern techniques or styles. This patch updates it in the
following ways:

  1. Use test_cmp instead of cmp (to make failures easier to
     debug).

  2. Use test_cmp instead of 'test $(command) = expected'.
     This makes failures much easier to debug, and also
     makes sure that $(command) exits appropriately.

  3. Use test_must_fail (easier to read, and checks more
     rigorously for signal death).

  4. Write tests with the usual style of:

       test_expect_success 'test name' '
               test commands &&
	       ...
       '

     rather than one-liners, or using backslash-continuation.
     This is purely a style fixup.

There are still a few command happening outside of
test_expect invocations, but they are all innoccuous system
commands like "cat" and "cp". In an ideal world, each test
would be self sufficient and all commands would happen
inside test_expect, but it is not immediately obvious how
the grouping should work (some of the commands impact the
subsequent tests, and some of them are setting up and
modifying state that many tests depend on). This patch just
picks the low-hanging style fruit, and we can do more fixes
on top later.

Signed-off-by: Jeff King <peff@peff.net>
t1300: remove redundant test

This test checks that git-config fails for an ambiguous
"get", but we check the exact same thing 3 tests beforehand.

Signed-off-by: Jeff King <peff@peff.net>
t1300: test "git config --get-all" more thoroughly

We check that we can "--get-all" a multi-valued variable,
but we do not actually confirm that the output is sensible.
Doing so reveals that it works fine, but this will help us
ensure we do not have regressions in the next few patches,
which will touch this area.

Signed-off-by: Jeff King <peff@peff.net>
git-config: remove memory leak of key regexp

This is only called once per invocation, so it's not a major
leak, but it's easy to fix.

Signed-off-by: Jeff King <peff@peff.net>
git-config: fix regexp memory leaks on error conditions

The get_value function has a goto label for cleaning up on
errors, but it only cleans up half of what the function
might allocate. Let's also clean up the key and regexp
variables there.

Note that we need to take special care when compiling the
regex fails to clean it up ourselves, since it is in a
half-constructed state (we would want to free it, but not
regfree it).

Similarly, we fix git_config_parse_key to return NULL when
it fails, not a pointer to some already-freed memory.

Signed-off-by: Jeff King <peff@peff.net>
git-config: collect values instead of immediately printing

This is a refactor that will allow us to more easily tweak
the behavior for multi-valued variables, and it will
ultimately allow us to remove a lot git-config's custom code
in favor of the regular git_config code.

It does mean we're no longer streaming, and we're storing
more in memory for the --get-all case, but in practice it is
a tiny amount of data, and the results are instantaneous.

Signed-off-by: Jeff King <peff@peff.net>
git-config: do not complain about duplicate entries

If git-config is asked for a single value, it will complain
and exit with an error if it finds multiple instances of
that value. This is unlike the usual internal config
parsing, however, which will generally overwrite previous
values, leaving only the final one. For example:

  [set a multivar]
  $ git config user.email one@example.com
  $ git config --add user.email two@example.com

  [use the internal parser to fetch it]
  $ git var GIT_AUTHOR_IDENT
  Your Name <two@example.com> ...

  [use git-config to fetch it]
  $ git config user.email
  one@example.com
  error: More than one value for the key user.email: two@example.com

This overwriting behavior is critical for the regular
parser, which starts with the lowest-priority file (e.g.,
/etc/gitconfig) and proceeds to the highest-priority file
($GIT_DIR/config). Overwriting yields the highest priority
value at the end.

Git-config solves this problem by implementing its own
parsing. It goes from highest to lowest priorty, but does
not proceed to the next file if it has seen a value.

So in practice, this distinction never mattered much,
because it only triggered for values in the same file. And
there was not much point in doing that; the real value is in
overwriting values from lower-priority files.

However, this changed with the implementation of config
include files. Now we might see an include overriding a
value from the parent file, which is a sensible thing to do,
but git-config will flag as a duplication.

This patch drops the duplicate detection for git-config and
switches to a pure-overwrite model (for the single case;
--get-all can still be used if callers want to do something
more fancy).

As is shown by the modifications to the test suite, this is
a user-visible change in behavior. An alternative would be
to just change the include case, but this is much cleaner
for a few reasons:

  1. If you change the include case, then to what? If you
     just stop parsing includes after getting a value, then
     you will get a _different_ answer than the regular
     config parser (you'll get the first value instead of
     the last value). So you'd want to implement overwrite
     semantics anyway.

  2. Even though it is a change in behavior for git-config,
     it is bringing us in line with what the internal
     parsers already do.

  3. The file-order reimplementation is the only thing
     keeping us from sharing more code with the internal
     config parser, which will help keep differences to a
     minimum.

Going under the assumption that the primary purpose of
git-config is to behave identically to how git's internal
parsing works, this change can be seen as a bug-fix.

Signed-off-by: Jeff King <peff@peff.net>
git-config: use git_config_with_options

The git-config command has always implemented its own file
lookup and parsing order. This was necessary because its
duplicate-entry handling did not match the way git's
internal callbacks worked. Now that this is no longer the
case, we are free to reuse the existing parsing code.

This saves us a few lines of code, but most importantly, it
means that the logic for which files are examined is
contained only in one place and cannot diverge.

Signed-off-by: Jeff King <peff@peff.net>
git-submodule: wrap branch option with "<>" in usage strings.

Use "-b <branch>" instead of "-b branch".  This brings the usage
strings in line with other options, e.g. "--reference <repository>".

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Jeff King <peff@peff.net>
Documentation: build html for all files in technical and howto

These files were recently revised to be valid asciidoc, so
there is no reason not to build html versions.

Signed-off-by: Thomas Ackermann <th.acker66@arcor.de>
Signed-off-by: Jeff King <peff@peff.net>
Doc SubmittingPatches: Mention --notes option after "cover letter"

The git format-patch --notes option can now insert the commit notes
after the three dashes. Mention this after the regular cover letter
guidance for submitting patches.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Jeff King <peff@peff.net>
Doc notes: Include the format-patch --notes option

git format-patch gained a --notes option. Tell the notes user.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Jeff King <peff@peff.net>
Merge branch 'jl/submodule-rm' into next

"git rm submodule" cannot blindly remove a submodule directory as
its working tree may have local changes, and worse yet, it may even
have its repository embedded in it.  Teach it some special cases
where it is safe to remove a submodule, specifically, when there is
no local changes in the submodule working tree, and its repository
is not embedded in its working tree but is elsewhere and uses the
gitfile mechanism to point at it.

Will merge to 'master' in the second batch after 1.8.0 ships.

* jl/submodule-rm:
  submodule: teach rm to remove submodules unless they contain a git directory
Merge branch 'jl/submodule-add-by-name' into next

If you remove a submodule, in order to keep the repository so that
"git checkout" to an older commit in the superproject history can
resurrect the submodule, the real repository will stay in $GIT_DIR
of the superproject.  A later "git submodule add $path" to add a
different submodule at the same path will fail.  Diagnose this case
a bit better, and if the user really wants to add an unrelated
submodule at the same path, give the "--name" option to give it a
place in $GIT_DIR of the superproject that does not conflict with
the original submodule.

Will merge to 'master' in the second batch after 1.8.0 ships.

* jl/submodule-add-by-name:
  submodule add: Fail when .git/modules/<name> already exists unless forced
  Teach "git submodule add" the --name option
Merge branch 'jc/grep-pcre-loose-ends' into next

"git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally.  The early part of this series is a fix for it.

Will merge to 'master' in the second batch after 1.8.0 ships.

* jc/grep-pcre-loose-ends:
  log: honor grep.* configuration
  log --grep: accept --basic-regexp and --perl-regexp
  log --grep: use the same helper to set -E/-F options as "git grep"
  revisions: initialize revs->grep_filter using grep_init()
  grep: move pattern-type bits support to top-level grep.[ch]
  grep: move the configuration parsing logic to grep.[ch]
  builtin/grep.c: make configuration callback more reusable
Merge branch 'km/send-email-compose-encoding' (early part) into next

* 'km/send-email-compose-encoding' (early part):
  git-send-email: introduce compose-encoding
Merge branch 'so/prompt-command' into next

Updates __git_ps1 so that it can be used as $PROMPT_COMMAND,
instead of being used for command substitution in $PS1, to embed
color escape sequences in its output.

* so/prompt-command:
  coloured git-prompt: paint detached HEAD marker in red
  Fix up colored git-prompt
  show color hints based on state of the git tree
  Allow __git_ps1 to be used in PROMPT_COMMAND
Merge branch 'jk/maint-http-init-not-in-result-handler' into next

Further clean-up to the http codepath that picks up results after
cURL library is done with one request slot.

Will merge to 'master' in the second batch after 1.8.0 ships.

* jk/maint-http-init-not-in-result-handler:
  http: do not set up curl auth after a 401
  remote-curl: do not call run_slot repeatedly
Merge branch 'nd/grep-true-path' into next

"git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.

Will merge to 'master' in the second batch after 1.8.0 ships.

* nd/grep-true-path:
  grep: stop looking at random places for .gitattributes
Merge branch 'rs/lock-correct-ref-during-delete' into next

When "update-ref -d --no-deref SYM" tried to delete a symbolic ref
SYM, it incorrectly locked the underlying reference pointed by SYM,
not the symbolic ref itself.

* rs/lock-correct-ref-during-delete:
  refs: lock symref that is to be deleted, not its target