The original version used relative approxidates, which don't
reproduce as reliably as absolute ones. Commit 6c647a fixed
this for one case, but missed the "silly" case.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* fk/threaded-grep:
  Threaded grep
  grep: expose "status-only" feature via -q

* gp/maint-cvsserver:
  git-cvsserver: allow regex metacharacters in CVSROOT

"diff --cc" output t4038 tests was fixed by b810cbbd (diff --cc: a lost
line at the beginning of the file is shown incorrectly, 2009-07-22), which
was actually the commit that introduced this test..

An error in "git merge -s resolve" t6035 tests was fixed by 730f7284
(unpack-trees.c: look ahead in the index, 2009-09-20).
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* jc/upstream-reflog:
  Fix log -g this@{upstream}

* jc/maint-reflog-bad-timestamp:
  t0101: use a fixed timestamp when searching in the reflog
  Update @{bogus.timestamp} fix not to die()
  approxidate_careful() reports errorneous date string

* il/maint-colon-address:
  Allow use of []-wrapped addresses in git://
  Support addresses with ':' in git-daemon

* il/maint-xmallocz:
  Fix integer overflow in unpack_compressed_entry()
  Fix integer overflow in unpack_sha1_rest()
  Fix integer overflow in patch_delta()
  Add xmallocz()

* jh/maint-config-file-prefix:
  builtin-config: Fix crash when using "-f <relative path>" from non-root dir

At the beginning of the function we make sure remote is not NULL, and
the remainder of the funciton already depends on it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

remote.<remote>.vcs causes remote->foreign_vcs to be set on entry to
transport_get(). Unfortunately, the code assumed that any such entry
is stale from previous round.

Fix this by making VCS set by URL to be volatile w.r.t. transport_get()
instead.
Signed-off-by: NIlari Liusvaara <ilari.liusvaara@elisanet.fi>
Acked-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

That will give us a better reproducibility during tests.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The caller will say "It is not a valid object name" if it wants to, and
some callers may even try to see if it names an object and otherwise try to
see if it is a path.

Pointed out by Jeff King.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* jl/diff-submodule-ignore:
  Teach diff --submodule that modified submodule directory is dirty
  git diff: Don't test submodule dirtiness with --ignore-submodules
  Make ce_uptodate() trustworthy again

Bash (4.0.24) on OpenBSD 4.6 refuses to run this snippet:

    $ cat gomi.sh
    #!/bin/sh
    one="/var/tmp/1 1"
    rm -f /var/tmp/1 "/var/tmp/1 1"
    echo hello >$one
    $ sh gomi.sh; ls /var/tmp/1*
    /var/tmp/1 1
    $ bash gomi.sh; ls /var/tmp/1*
    gomi.sh: line 4: $one: ambiguous redirect
    ls: /var/tmp/1*: No such file or directory

Every competent shell programmer knows that a <$word in redirection is not
subject to field splitting (POSIX.1 "2.7 Redirection" explicitly lists the
kind of expansion performed: "... the word that follows the redirection
operator shall be subjected to ...", and "Field Splitting" is not among
them).

Some clueless folks apparently decided that users need to be protected in
the name of "security", however.

Output from "git grep -e '> *\$' -- '*.sh'" indicates that rebase-i
suffers from this bogus "safety".  Work it around by surrounding the
variable reference with a dq pair.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Using a dollar sign in double quotes isn't portable. Escape them with
a backslash or replace the double quotes with single quotes.
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

For a long time, the time based reflog syntax (e.g. master@{yesterday})
didn't complain when the "human readable" timestamp was misspelled, as
the underlying mechanism tried to be as lenient as possible.  The funny
thing was that parsing of "@{now}" even relied on the fact that anything
not recognized by the machinery returned the current timestamp.

Introduce approxidate_careful() that takes an optional pointer to an
integer, that gets assigned 1 when the input does not make sense as a
timestamp.

As I am too lazy to fix all the callers that use approxidate(), most of
the callers do not take advantage of the error checking, but convert the
code to parse reflog to use it as a demonstration.

Tests are mostly from Jeff King.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It showed the correct objects but walked a wrong reflog.
Again, tests are from Jeff King.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NIlari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

[jc: later NUL termination by the caller becomes unnecessary]
Signed-off-by: NIlari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NIlari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Add routine for allocating NUL-terminated memory block without risking
integer overflow in addition of +1 for NUL byte.

[jc: with suggestion from Bill Lear]
Signed-off-by: NIlari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When run in a repository with a path name containing regex metacharacters
(e.g. +), git-cvsserver failed to split the client request into CVSROOT
and module.  Now metacharacters are disabled for the value of CVSROOT in
the perl regex so that directory names containing metacharacters are
handled properly.
Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When your current directory is not at the root of the working tree, and you
use the "-f" option with a relative path, the current code tries to read
from a wrong file, since argv[2] is now beyond the end of the rearranged
argument list.

This patch replaces the incorrect argv[2] with the variable holding the
given config file name.

The bug was introduced by d64ec16c (git config: reorganize to use parseopt).

[jc: added test]
Signed-off-by: NJohan Herland <johan@herland.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Allow using "["<host>"]":<port> and "["<host>"]" notations in git://
host addresses. This is needed to be able to connect to addresses
that contain ':' (e.g. numeric IPv6 addresses). Also send the host
header []-wrapped so it can actually be parsed by remote end.
Signed-off-by: NIlari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If host address could have ':' in it (e.g. numeric IPv6 address), then
host and port could not be uniquely parsed. Fix this by parsing the
"["<host>"]":<port> and "["<host>"]" notations. Currently the built-in
git:// client would send <host>:<port> or <host> for such thing, but
it doesn't matter as due to bugs, resolving address fails if <host>
contains ':'.
Signed-off-by: NIlari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

BSD and glibc have an extension to regexec which takes a buffer + length pair
instead of a NUL-terminated string. Since we already have the length computed
this can save us a strlen call inside regexec.
Signed-off-by: NBenjamin Kramer <benny.kra@googlemail.com>
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Make git grep use threads when it is available.

The results below are best of five runs in the Linux repository (on a
box with two cores).

With the patch:

git grep qwerty
1.58user 0.55system 0:01.16elapsed 183%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+800outputs (0major+5774minor)pagefaults 0swaps

Without:

git grep qwerty
1.59user 0.43system 0:02.02elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+800outputs (0major+3716minor)pagefaults 0swaps

And with a pattern with quite a few matches:

With the patch:

$ /usr/bin/time git grep void
5.61user 0.56system 0:03.44elapsed 179%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+800outputs (0major+5587minor)pagefaults 0swaps

Without:

$ /usr/bin/time git grep void
5.36user 0.51system 0:05.87elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+800outputs (0major+3693minor)pagefaults 0swaps

In either case we gain about 40% by the threading.
Signed-off-by: NFredrik Kuivinen <frekui@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The patch detection wants to inspect all the headers of a rfc2822 message
and ensure that they look like header fields. The headers are always
separated from the message body with a blank line. When Thunderbird saves
the message the blank line separating the headers from the body includes a
CR. The patch detection is failing because a CRLF doesn't match /^$/. Fix
this by allowing a CR to exist on the separating line.
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We shouldn't have literal CR's in tests as they aren't portable.
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

append_cr(), remove_cr(), q_to_nul() and q_to_cr() are defined in multiple
tests. Consolidate them into test-lib.sh so we can stop redefining them.
The use of remove_cr() in t0020 to test for a CR is replaced with a new
function has_cr() to accurately reflect what is intended (the output of
remove_cr() was being thrown away).
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Teach "git grep" a new "-q" option to report the presense of a match via
its exit status without showing any output, similar to how "grep -q"
works.  Internally "grep" engine already knew this "status-only" mode of
operation because it needed to grep inside log message to filter commits
when called from the "git log" machinery, and this patch only exposes it
to the command line tool.

A somewhat unfair benchmark in the Linux kernel directory shows a dramatic
improvement:

    (with patch)
    $ time ../git.git/git grep -q linux HEAD ; echo $?

    real    0m0.030s
    user    0m0.004s
    sys     0m0.004s
    0

    (without patch)
    $ time git grep linux HEAD >/dev/null; echo $?

    real    0m4.432s
    user    0m4.272s
    sys     0m0.076s
    0

This is "somewhat unfair" because I knew a file with such a string comes
very early in the tree traversal (namely, ".gitignore").
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

Don't feed a multiple-line pattern to grep and expect the them to match
with lines in order.

Simplify the grep expressions in the non-fast-forward tests to check
only for the first line of the non-fast-forward warning - having that
line should be enough assurance that the full warning is printed.
Signed-off-by: NTay Ray Chuan <rctay89@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Use the modern form of printing a commit subject instead of piping
the output of rev-list to sed.
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Add test-run-command to .gitignore so it does not pollute
git status output.
Signed-off-by: NAlejandro Riveira Fernández <ariveira@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This is a followup to ac0ba18d (run-command: convert simple callsites to
use_shell, 2009-12-30), for consistency.
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Since commit 8e08b4 git diff does append "-dirty" to the work tree side
if the working directory of a submodule contains new or modified files.
Lets do the same when the --submodule option is used.
Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The diff family suppresses the output of submodule changes when
requested but checks them nonetheless. But since recently submodules
get examined for their dirtiness, which is rather expensive. There is
no need to do that when the --ignore-submodules option is used, as
the gathered information is never used anyway.
Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In Internet Explorer 8 (IE8) the 'blame_incremental' view, which uses
JavaScript to generate blame info using AJAX, sometimes hang at the
beginning (at 0%) of blaming, e.g. for larger files with long history
like git's own gitweb/gitweb.perl.

The error shown by JavaScript console is "Unspecified error" at char:2
of the following line in gitweb/gitweb.js:

  if (xhr.readyState === 3 && xhr.status !== 200) {

Debugging it using IE8 JScript debuger shown that the error occurs
when trying to access xhr.status (xhr is XMLHttpRequest object).
Watch for xhr object shows 'Unspecified error.' as "value" of
xhr.status, and trying to access xhr.status from console throws error.

This bug is some intermittent bug, depending on XMLHttpRequest timing,
as it doesn't occur in all cases.  It is probably caused by the fact
that handleResponse is called from timer (pollTimer), to work around
the fact that some browsers call onreadystatechange handler only once
for each state change, and not like required for 'blame_incremental'
as soon as new data is available from server.  It looks like xhr
object is not properly initialized; still it is a bug to throw an
error when accessing xhr.status (and not use 'null' or 'undefined' as
value).

Work around this bug in IE8 by using try-catch block when accessing
xhr.status.
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>