status: fix bug with missing --ignore files

Commit 1b908b6 (wt-status: rename and restructure
status-print-untracked, 2010-04-10) converted the
wt_status_print_untracked function into
wt_status_print_other, taking a string_list of either
untracked or ignored items to print. However, the "nothing
to show" early return still checked the wt_status->untracked
list instead of the passed-in list.

That meant that if we had ignored items to show, but no
untracked items, we would erroneously exit early and fail to
show the ignored items.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git status --ignored: tests and docs

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
tag: speed up --contains calculation

When we want to know if commit A contains commit B (or any
one of a set of commits, B through Z), we generally
calculate the merge bases and see if B is a merge base of A
(or for a set, if any of the commits B through Z have that
property).

When we are going to check a series of commits A1 through An
to see whether each contains B (e.g., because we are
deciding which tags to show with "git tag --contains"), we
do a series of merge base calculations. This can be very
expensive, as we repeat a lot of traversal work.

Instead, let's leverage the fact that we are going to use
the same --contains list for each tag, and mark areas of the
commit graph is definitely containing those commits, or
definitely not containing those commits. Later tags can then
stop traversing as soon as they see a previously calculated
answer.

This sped up "git tag --contains HEAD~200" in the linux-2.6
repository from:

  real    0m15.417s
  user    0m15.197s
  sys     0m0.220s

to:

  real    0m5.329s
  user    0m5.144s
  sys     0m0.184s

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
strbuf_split: add a max parameter

Sometimes when splitting, you only want a limited number of
fields, and for the final field to contain "everything
else", even if it includes the delimiter.

This patch introduces strbuf_split_max, which provides a
"max number of fields" parameter; it behaves similarly to
perl's "split" with a 3rd field.

The existing 2-argument form of strbuf_split is retained for
compatibility and ease-of-use.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fix "git -c" parsing of values with equals signs

If you do something like:

  git -c core.foo="value with = in it" ...

we would split your option on "=" into three fields and
throw away the third one. With this patch we correctly take
everything after the first "=" as the value (keys cannot
have an equals sign in them, so the parsing is unambiguous).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
config: die on error in command-line config

The error handling for git_config is somewhat confusing. We
collect errors from running git_config_from_file on the
various config files and carefully pass them back up. But
the two odd things are:

  1. We actually die on most errors in git_config_from_file.
     In fact, the only error we actually pass back up is if
     fopen() fails on the file.

  2. Most callers of git_config do not check the error
     return at all, but will continue if git_config reports
     an error.

When the code for "git -c core.foo=bar" was added, it
dutifully passed errors up the call stack, only for them to
be eventually ignored. This makes it inconsistent with the
file-parsing code, which will die when it sees malformed
config. And it's somewhat unsafe, because it means an error
in parsing a typo like:

  git -c clean.requireforce=ture clean

will continue the command, ignoring the config the user
tried to give.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
config: avoid segfault when parsing command-line config

We already check for an empty key on the left side of an
equals, but we would segfault if there was no content at
all.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
strbuf: allow strbuf_split to work on non-strbufs

The strbuf_split function takes a strbuf as input, and
outputs a list of strbufs. However, there is no reason that
the input has to be a strbuf, and not an arbitrary buffer.

This patch adds strbuf_split_buf for a length-delimited
buffer, and strbuf_split_str for NUL-terminated strings.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
config: use strbuf_split_str instead of a temporary strbuf

This saves an allocation and copy, and also fixes a minor
memory leak.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: quote double-dash for AsciiDoc

AsciiDoc versions since 5.0.6 treat a double-dash surrounded by spaces
(outside of verbatim environments) as a request to insert an em dash.
Such versions also treat the three-character sequence "\--", when not
followed by another dash, as a request to insert two literal minus
signs.  Thus from time to time there have been patches to add
backslashes to AsciiDoc markup to escape double-dashes that are meant
to be represent '--' characters used literally on the command line;
see v1.4.0-rc1~174, Fix up docs where "--" isn't displayed correctly,
2006-05-05, for example.

AsciiDoc 6.0.3 (2005-04-20) made life harder by also treating
double-dashes without surrounding whitespace as markup for an em dash,
though only when formatting for backends other than the manpages
(e.g., HTML).  Many pages needed to be changed to use a backslash
before the "--" in names of command-line flags like "--add" (see
v0.99.6~37, Update tutorial, 2005-08-30).

AsciiDoc 8.3.0 (2008-11-29) refined the em-dash rule to avoid that
requirement.  Double-dashes without surrounding spaces are not
rendered as em dashes any more unless bordered on both sides by
alphanumeric characters.  The unescaped markup for option names (e.g.,
"--add") works fine, and many instances of this style have leaked into
Documentation/; git's HTML documentation contains many spurious em
dashes when formatted by an older toolchain.  (This patch will not
change that.)

The upshot: "--" as an isolated word and in phrases like "git
web--browse" must be escaped if it is not to be rendered as an em dash
by current asciidoc.  Use "\--" to avoid such misformatting in
sentences in which "--" represents a literal double-minus command line
argument that separates options and revs from pathspecs, and use
"{litdd}" in cases where the double-dash is embedded in the command
name.  The latter is just for consistency with v1.7.3-rc0~13^2 (Work
around em-dash handling in newer AsciiDoc, 2010-08-23).

List of lines to fix found by grepping manpages for "(em".

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Junio C Hamano <gitster@pobox.com>
Improved-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jn/maint-doc-dashdash' into jn/doc-dashdash

* jn/maint-doc-dashdash:
  Documentation: quote double-dash for AsciiDoc
Documentation/i18n: quote double-dash for AsciiDoc

As explained in v1.7.3-rc0~13^2 (Work around em-dash handling in newer
AsciiDoc, 2010-08-23), if double dashes in names of commands are not
escaped, AsciiDoc renders them as em dashes.

While fixing that, spell the command name as "git sh-i18n--envsubst"
(2 words) instead of emphasizing the name of the binary (one
hyphenated name) and format it in italics.

The double-dash in the title should be escaped, too, to avoid spurious
em dashes in the header:

  .TH "GIT\-SH\-I18N\(emENVSUB" "1" "06/26/2011" "Git 1\&.7\&.6" "Git Manual"

AsciiDoc 8.6.4 with DocBook XSL 1.76.0-RC1 copes fine and writes
"GIT\-SH\-I18N\-\-ENVSUB" even without this change, which is why it
was missed before.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
mergetool: check return value from read

The process may not even have the standard input open in which case it
will get stuck in an infinite loop to prompt and read nothing.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Do not log unless all connect() attempts fail

IPv6 hosts are often unreachable on the primarily IPv4 Internet and
therefore we shouldn't print an error if there are still other hosts we
can try to connect() to. This helps "git fetch --quiet" stay quiet.

Signed-off-by: Dave Zarzycki <zarzycki@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
tests: cleanup binary test vector files

The test4012.png test vector file that was originally used for t4012 to
check operations on binary files was later reused in other tests, making
it no longer consistent to name it after a specific test. Rename it to more
generic "test-binary-1.png".

While at it, rename test9200b to "test-binary-2.png" (even though it is
only used by t9200).

Signed-off-by: Vitaliy Ivanov <vitalivanov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
reset: give better reflog messages

The reset command creates its reflog entry from argv.
However, it does so after having run parse_options, which
means the only thing left in argv is any non-option
arguments. Thus you would end up with confusing reflog
entries like:

  $ git reset --hard HEAD^
  $ git reset --soft HEAD@{1}
  $ git log -2 -g --oneline
  8e46cad HEAD@{0}: HEAD@{1}: updating HEAD
  1eb9486 HEAD@{1}: HEAD^: updating HEAD

However, we must also consider that some scripts may set
GIT_REFLOG_ACTION before calling reset, and we need to show
their reflog action (with our text appended). For example:

  rebase -i (squash): updating HEAD

On top of that, we also set the ORIG_HEAD reflog action
(even though it doesn't generally exist). In that case, the
reset argument is somewhat meaningless, as it has nothing to
do with what's in ORIG_HEAD.

This patch changes the reset reflog code to show:

  $GIT_REFLOG_ACTION: updating {HEAD,ORIG_HEAD}

as before, but only if GIT_REFLOG_ACTION is set. Otherwise,
show:

   reset: moving to $rev

for HEAD, and:

   reset: updating ORIG_HEAD

for ORIG_HEAD (this is still somewhat superfluous, since we
are in the ORIG_HEAD reflog, obviously, but at least we now
mention which command was used to update it).

While we're at it, we can clean up the code a bit:

 - Use strbufs to make the message.

 - Use the "rev" parameter instead of showing all options.
   This makes more sense, since it is the only thing
   impacting the writing of the ref.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
reflog: actually default to subcommand 'show'

The reflog manpage says:

	git reflog [show] [log-options] [<ref>]

the subcommand 'show' is the default "in the absence of any
subcommands". Currently this is only true if the user provided either
at least one option or no additional argument at all. For example:

	git reflog master

won't work. Change this by actually calling cmd_log_reflog in
absence of any subcommand.

Signed-off-by: Michael Schubert <mschub@elegosoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch: skip on-demand checking when no submodules are configured

It makes no sense to do the - possibly very expensive - call to "rev-list
<new-ref-sha1> --not --all" in check_for_new_submodule_commits() when
there aren't any submodules configured.

Leave check_for_new_submodule_commits() early when no name <-> path
mappings for submodules are found in the configuration. To make that work
reading the configuration had to be moved further up in cmd_fetch(), as
doing that after the actual fetch of the superproject was too late.

Reported-by: Martin Fick <mfick@codeaurora.org>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
SubmittingPathces: remove Cogito reference

Removing Cogito leaves just git and StGit, which is a rather
incomplete list of git diff tools available. Sidestep the problem
of deciding what tools to mention by not mentioning any.

Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jk/maint-1.7.2-status-ignored' into maint

* jk/maint-1.7.2-status-ignored:
  git status --ignored: tests and docs
  status: fix bug with missing --ignore files

Conflicts:
	Documentation/git-status.txt
	t/t7508-status.sh