This doesn't actually change the external interfaces, so they are still
thread-unsafe, but it makes the code internally pass a pointer to a
local 'struct cache_def' around, so that the core code can be made
thread-safe.
The threaded index preloading will want to verify that the paths leading
up to a pathname are all real directories.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we have an up-to-date index entry for a file in that directory, we
can know that the directories leading up to that file must be
directories. No need to do an lstat() on the directory.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a git command executes a subcommand, it uses the "git
foo" form, which relies on finding "git" in the PATH.
Normally this should not be a problem, since the same "git"
that was used to invoke git in the first place will be
found. And if somebody invokes a "git" outside of the PATH
(e.g., by giving its absolute path), this case is already
covered: we put that absolute path onto the front of PATH.
However, if one is using "sudo", then sudo will execute the
"git" from the PATH, but pass along a restricted PATH that
may not contain the original "git" directory. In this case,
executing a subcommand will fail.
To solve this, we put the "git" wrapper itself into the
execdir; this directory is prepended to the PATH when git
starts, so the wrapper will always be found.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On filesystems without d_type, we can look at the cache entry first.
Doing an lstat() can be expensive.
Reported by Dmitry Potapov for Cygwin.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Stop the insanity with separate 'path' and 'base' arguments that must
match. We don't need that crazy interface any more, since we cleaned up
handling of 'path' in commit da4b3e8c28.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of the users of "read_directory()" actually want a much simpler
interface than the whole complex (but rather powerful) one.
In fact 'git add' had already largely abstracted out the core interface
issues into a private "fill_directory()" function that was largely
applicable almost as-is to a number of callers. Yes, 'git add' wants to
do some extra work of its own, specific to the add semantics, but we can
easily split that out, and use the core as a generic function.
This function does exactly that, and now that much simplified
'fill_directory()' function can be shared with a number of callers,
while also ensuring that the rather more complex calling conventions of
read_directory() are used by fewer call-sites.
This also makes the 'common_prefix()' helper function private to dir.c,
since all callers are now in that file.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* gb/gitweb-avatar:
gitweb: add empty alt text to avatar img
gitweb: picon avatar provider
gitweb: gravatar url cache
gitweb: (gr)avatar support
gitweb: use git_print_authorship_rows in 'tag' view too
gitweb: uniform author info for commit and commitdiff
gitweb: refactor author name insertion
* rs/grep-p:
grep: simplify -p output
grep -p: support user defined regular expressions
grep: add option -p/--show-function
grep: handle pre context lines on demand
grep: print context hunk marks between files
grep: move context hunk mark handling into show_line()
userdiff: add xdiff_clear_find_func()
git-format-patch prepends patches with a [PATCH x/n] prefix, but
mailinfo used to remove any number of square-bracket pairs and
the content between them. This prevents one from using a commit
subject like this:
[ and ] must be allowed as input
Removing the square bracket pair from this rather clumsily
constructed subject line loses important information, so we must
take care not to.
This patch causes the subject stripping to stop after it has
encountered one pair of square brackets.
One possible downside of this patch is that the patch-handling
programs will now fail at removing author-added square-brackets
to be removed, such as
[RFC][PATCH x/n]
However, since format-patch only adds one set of square brackets,
this behaviour is quite easily undesrstood and defended while the
previous behaviour is not.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
- correctly link paragraphs within list items
- consistently format examples
- put option alernatives on separate lines
- always use [verse] for config items
- always indent 1st paragraph of a list item, with a tab
Signed-off-by: Yann Dirson <ydirson@altern.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also consistently use single quotes around git commands to make things clear
(was only needed at a couple of places).
Signed-off-by: Yann Dirson <ydirson@altern.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Aliases that invoke shell commands start from the top-level directory,
but this was not documented.
Signed-off-by: Sitaram Chamarty <sitaramc@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 0065236 (bash completion: complete variable names for "git
config" with options 2009-05-08) implemented its config variable search
wrong. When a config contains a value with a space and a period (.) in
it, completion erroneously thinks that line in the configuration is
multiple config variables.
For example
$ cat .git/config
format.cc = Junio C Hamano <gitster@pobox.com>
$ git config --unset <TAB>
format.cc
<gitster@pobox.com>
Instead of using a for loop splitting across spaces, pipe each line to a
while read loop and beef up the case statement to match only
'config.variable=value'.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/die_errno:
Use die_errno() instead of die() when checking syscalls
Convert existing die(..., strerror(errno)) to die_errno()
die_errno(): double % in strerror() output just in case
Introduce die_errno() that appends strerror(errno) to die()
Using it will generate a perl warning "\1 better written as $1".
Signed-off-by: Nick Woolley <git.wu-lee@noodlefactory.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is common practice to use the Unix epoch as a fallback date
when a suitable date is not available. This is true of git svn
and possibly other importing tools that import non-git history
into git.
Instead of clobbering established strtoul() error reporting
semantics with our own, preserve the strtoul() error value
of ULONG_MAX for fsck.c to handle.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
xml_entities() in http-push.c did not properly stop at the end of the
string being examined, which would occasionally cause nonsense to be
appended to escaped URL strings and result in failed DAV XML queries
Signed-off-by: Seth Hunter <hunter@ll.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function run_status was used to report failures after a hook was run.
By now, the only thing that the function itself reported was the exit code
of the hook (if it was non-zero). But this is redundant because it can be
expected that the hook itself will have reported a suitable error.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the case where a program was not found, it was still the task of the
caller to report an error to the user. Usually, this is an interesting case
but only few callers actually reported a specific error (though many call
sites report a generic error message regardless of the cause).
With this change the error is reported by run_command, but since there is
one call site in git.c that does not want that, an option is added to
struct child_process, which is used to turn the error off.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We now write the signal number in the error message if the program
terminated by a signal. The negative return value is constructed such that
after truncation to 8 bits it looks like a POSIX shell's $?:
$ echo 0000 | { git upload-pack .; echo $? >&2; } | :
error: git-upload-pack died of signal 13
141
Previously, the exit code was 255 instead of 141.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As a general guideline, functions in git's code return zero to indicate
success and negative values to indicate failure. The run_command family of
functions followed this guideline. But there are actually two different
kinds of failure:
- failures of system calls;
- non-zero exit code of the program that was run.
Usually, a non-zero exit code of the program is a failure and means a
failure to the caller. Except that sometimes it does not. For example, the
exit code of merge programs (e.g. external merge drivers) conveys
information about how the merge failed, and not all exit calls are
actually failures.
Furthermore, the return value of run_command is sometimes used as exit
code by the caller.
This change arranges that the exit code of the program is returned as a
positive value, which can now be regarded as the "result" of the function.
System call failures continue to be reported as negative values.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Windows does not have signals. At least they cannot be diagnosed by the
parent process; all that the parent process can observe is the exit code.
This also adds a dummy definition of WTERMSIG.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For some reason, MinGW's bash cannot reliably detect failure of the child
process if a negative value is passed to exit(). This fixes it by
truncating the exit code in all calls of exit().
This issue was worked around in run_builtin() of git.c (2488df84 builtin
run_command: do not exit with -1, 2007-11-15). This workaround is no longer
necessary and is reverted.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was found a bit too loud to show == separators between the function
headers.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Put filenames into the conflict markers only when they are different.
Otherwise they are redundant information clutter.
Print the filename explicitely when warning about a binary conflict.
Signed-off-by: Martin Renold <martinxyz@gmx.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cc/bisect:
Documentation: remove warning saying that "git bisect skip" may slow bisection
bisect: use a PRNG with a bias when skipping away from untestable commits
* js/daemon-log:
receive-pack: do not send error details to the client
upload-pack: squelch progress indicator if client cannot see it
daemon: send stderr of service programs to the syslog
* sb/quiet-porcelains:
stash: teach quiet option
am, rebase: teach quiet option
submodule, repack: migrate to git-sh-setup's say()
git-sh-setup: introduce say() for quiet options
am: suppress apply errors when using 3-way
t4150: test applying with a newline in subject
Respect the userdiff attributes and config settings when looking for
lines with function definitions in git grep -p.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new option -p instructs git grep to print the previous function
definition as a context line, similar to diff -p. Such context lines
are marked with an equal sign instead of a dash. This option
complements the existing context options -A, -B, -C.
Function definitions are detected using the same heuristic that diff
uses. User defined regular expressions are not supported, yet.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Factor out pre context line handling into the new function
show_pre_context() and change the algorithm to rewind by looking for
newline characters and roll forward again, instead of maintaining an
array of line beginnings and ends.
This is slower for hits, but the cost for non-matching lines becomes
zero. Normally, there are far more non-matching lines, so the time
spent in total decreases.
Before this patch (current Linux kernel repo, best of five runs):
$ time git grep --no-ext-grep -B1 memset >/dev/null
real 0m2.134s
user 0m1.932s
sys 0m0.196s
$ time git grep --no-ext-grep -B1000 memset >/dev/null
real 0m12.059s
user 0m11.837s
sys 0m0.224s
The same with this patch:
$ time git grep --no-ext-grep -B1 memset >/dev/null
real 0m2.117s
user 0m1.892s
sys 0m0.228s
$ time git grep --no-ext-grep -B1000 memset >/dev/null
real 0m2.986s
user 0m2.696s
sys 0m0.288s
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
