* jk/diff-highlight:
diff-highlight: document some non-optimal cases
diff-highlight: match multi-line hunks
diff-highlight: refactor to prepare for multi-line hunks
diff-highlight: don't highlight whole lines
diff-highlight: make perl strict and warnings fatal
* jk/grep-binary-attribute:
grep: pre-load userdiff drivers when threaded
grep: load file data after checking binary-ness
grep: respect diff attributes for binary-ness
grep: cache userdiff_driver in grep_source
grep: drop grep_buffer's "name" parameter
convert git-grep to use grep_source interface
grep: refactor the concept of "grep source" into an object
grep: move sha1-reading mutex into low-level code
grep: make locking flag global
* nd/find-pack-entry-recent-cache-invalidation:
find_pack_entry(): do not keep packed_git pointer locally
sha1_file.c: move the core logic of find_pack_entry() into fill_pack_entry()
* fc/zsh-completion:
completion: simplify __gitcomp and __gitcomp_nl implementations
completion: use ls -1 instead of rolling a loop to do that ourselves
completion: work around zsh option propagation bug
open_or_add_dir checks to see if the directory already exists or not.
If it already exists and is not a directory, then we fail. However,
open_or_add_dir did not previously account for the possibility that the
path did exist as a file, but is deleted in the current commit.
In order to prevent this legitimate case from failing, open_or_add_dir
needs to know what files are deleted in the current commit.
Unfortunately that information has to be plumbed through a couple of
layers.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
If we delete a file and recreate it as a directory in a single commit,
we have to tell the server about the deletion first or else we'll get
"RA layer request failed: Server sent unexpected return value (405
Method Not Allowed) in response to MKCOL request"
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Use numerical form of time zone to replace alphabetic time zone
abbreviation generated by "%Z". "%Z" is not portable and contain
ambiguity for many areas. For example, CST could be "Central
Standard Time" (GMT-0600) and "China Standard Time" (GMT+0800).
Alphabetic time zone abbreviation is meant for human readability,
not for specifying a time zone for machines.
Failed case can be illustrated like this in linux shell:
> echo $TZ
Asia/Taipei
> date +%Z
CST
> env TZ=`date +%Z` date
Mon Dec 19 06:03:04 CST 2011
> date
Mon Dec 19 14:03:04 CST 2011
[ew: fixed bad package reference inside Git::SVN::Log]
Signed-off-by: Wei-Yin Chen (陳威尹) <chen.weiyin@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Change git-svn to use git-rev-list(1) instead of git-log(1) since the
latter is porcelain that'll cause "git svn rebase" to fail completely
if log.abbrevCommit is set to true in the configuration.
Without this patch the code will fail to parse a SHA1, and then just
spew a bunch of "Use of uninitialized value $hash in string eq"
warnings at "if ($c && $c eq $hash) { ..." and never do anything
useful.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Change an invocation of git-rev-list(1) to not use --no-color,
git-rev-list(1) will always ignore that option and the --color option,
so there's no need to pass it.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
see afd7f1e for more details on git svn dcommit --interactive
Signed-off-by: Frederic Heitzmann <frederic.heitzmann@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
If a filter is not defined or if it fails, git should behave as if the
filter is a no-op passthru.
However, if the filter exits before reading all the content, depending on
the timing, git could be killed with SIGPIPE when it tries to write to the
pipe connected to the filter.
Ignore SIGPIPE while processing the filter to give us a chance to check
the return value from a failed write, in order to detect and act on this
mode of failure in a more controlled way.
Signed-off-by: Jehan Bing <jehan@orb.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the argument for `__git_ps1` begins with a dash, `printf` tries to
interpret it as an option which results in an error message.
The problem is solved by adding '--' before the argument to tell
`printf` to not interpret the following argument as an option.
Adding '--' directly to the argument does not help because the argument
is enclosed by double quotes.
Signed-off-by: Christian Hammerl <info@christian-hammerl.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current configure script uses -lintl if gettext is not found in the C
library, but does so before checking if there is libintl.h available in
the first place, in which case we would later define NO_GETTEXT.
Instead, check for the existence of libintl.h first. Only when libintl.h
exists and libintl is not in libc, ask for -lintl.
Signed-off-by: John Szakmeister <john@szakmeister.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The canonical order of command line arguments is always to have dashed
commands before other parameters, but the "git remote set-branches"
subcommand was described to take "name" before an optional "--add".
Signed-off-by: Philip Jägenstedt <philip@foolip.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit ff7f218 (gitweb: Fix file links in "grep" search, 2012-01-05),
added $file_href variable, to reduce duplication and have the fix
applied in single place.
Unfortunately it made variable defined inside the loop, not taking into
account the fact that $file_href was set only if file changed.
Therefore for files with multiple matches $file_href was undefined for
second and subsequent matches.
Fix this bug by moving $file_href declaration outside loop.
Adds tests for almost all forms of sarch in gitweb, which were missing
from testuite. Note that it only tests if there are no warnings, and
it doesn't check that gitweb finds what it should find.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running "git add --refresh <pathspec>", we incorrectly showed the
path that is unmerged even if it is outside the specified pathspec, even
though we did honor pathspec and refreshed only the paths that matched.
Note that this cange does not affect "git update-index --refresh"; for
hysterical raisins, it does not take a pathspec (it takes real paths) and
more importantly itss command line options are parsed and executed one by
one as they are encountered, so "git update-index --refresh foo" means
"first refresh the index, and then update the entry 'foo' by hashing the
contents in file 'foo'", not "refresh only entry 'foo'".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a repository whose HEAD points to an unborn branch with no commits,
"heads" view and "summary" view (which shows what is shown in "heads"
view) compared the object names of commits at the tip of branches with the
output from "git rev-parse HEAD", which caused comparison of a string with
undef and resulted in a warning in the server log.
This can happen if non-bare repository (with default 'master' branch)
is updated not via committing but by other means like push to it, or
Gerrit. It can happen also just after running "git checkout --orphan
<new branch>" but before creating any new commit on this branch.
Rewrite the comparison so that it also works when $head points at nothing;
in such a case, no branch can be "the current branch", add a test for it.
While at it, rename local variable $head to $head_at, as it points to
current commit rather than current branch name (HEAD contents).
The code still incorrectly shows all branches that point at the same
commit as what HEAD points as "the current branch", even when HEAD is
detached. Fixing this bug is outside the scope of this patch.
Reported-by: Rajesh Boyapati
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The only catch is that we don't really know what our repo contains, so
we have to ignore any possible "not found" status from git-grep.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This introduces a performance testing framework under t/perf/. It
tries to be as close to the test-lib.sh infrastructure as possible,
and thus should be easy to get used to for git developers.
The following points were considered for the implementation:
1. You usually want to compare arbitrary revisions/build trees against
each other. They may not have the performance test under
consideration, or even the perf-lib.sh infrastructure.
To cope with this, the 'run' script lets you specify arbitrary
build dirs and revisions. It even automatically builds the revisions
if it doesn't have them at hand yet.
2. Usually you would not want to run all tests. It would take too
long anyway. The 'run' script lets you specify which tests to run;
or you can also do it manually. There is a Makefile for
discoverability and 'make clean', but it is not meant for
real-world use.
3. Creating test repos from scratch in every test is extremely
time-consuming, and shipping or downloading such large/weird repos
is out of the question.
We leave this decision to the user. Two different sizes of test
repos can be configured, and the scripts just copy one or more of
those (using hardlinks for the object store). By default it tries
to use the build tree's git.git repository.
This is fairly fast and versatile. Using a copy instead of a clone
preserves many properties that the user may want to test for, such
as lots of loose objects, unpacked refs, etc.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This just moves all the user-facing functions to a separate file and
sources that instead.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).
This patch introduces an include directive for config files.
It looks like:
[include]
path = /path/to/file
This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).
The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.
Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:
1. Parsing of other config-like files, like .gitmodules.
There isn't a real need, and I'd rather be conservative
and avoid unnecessary incompatibility or confusion.
2. Reading single files via "git config". This is for two
reasons:
a. backwards compatibility with scripts looking at
config-like files.
b. inspection of a specific file probably means you
care about just what's in that file, not a general
lookup for "do we have this value anywhere at
all". If that is not the case, the caller can
always specify "--includes".
3. Writing files via "git config"; we want to treat
include.* variables as literal items to be copied (or
modified), and not expand them. So "git config
--unset-all foo.bar" would operate _only_ on
.git/config, not any of its included files (just as it
also does not operate on ~/.gitconfig).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a magic global variable that was intended as an
override to the usual git-config lookup process. Once upon a
time, you could specify GIT_CONFIG to any git program, and
it would look only at that file. This turned out to be
confusing and cause a lot of bugs for little gain. As a
result, dc87183 (Only use GIT_CONFIG in "git config", not
other programs, 2008-06-30) took this away for all callers
except git-config.
Since git-config no longer uses it either, the variable can
just go away. As the diff shows, nobody was setting to
anything except NULL, so we can just replace any sites where
it was read with NULL.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-config command sometimes operates on the default set
of config files (either reading from all, or writing to repo
config), and sometimes operates on a specific file. In the
latter case, we set the magic global config_exclusive_filename,
and the code in config.c does the right thing.
Instead, let's have git-config use the "advanced" variants
of config.c's functions which let it specify an individual
filename (or NULL for the default). This makes the code a
lot more obvious, and fixes two small bugs:
1. A relative path specified by GIT_CONFIG=foo will look
in the wrong directory if we have to chdir as part of
repository setup. We already handle this properly for
"git config -f foo", but the GIT_CONFIG lookup used
config_exclusive_filename directly. By dropping to a
single magic variable, the GIT_CONFIG case now just
works.
2. Calling "git config -f foo --edit" would not respect
core.editor. This is because just before editing, we
called git_config, which would respect the
config_exclusive_filename setting, even though this
particular git_config call was not about looking in the
user's specified file, but rather about loading actual
git config, just as any other git program would.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Callers may want to provide a specific version of a file in which to look
for config. Right now this can be done by setting the magic global
config_exclusive_filename variable. By providing a version of git_config
that takes a filename, we can take a step towards making this magic global
go away.
Furthermore, by providing a more "advanced" interface, we now have a a
natural place to add new options for callers like git-config, which care
about tweaking the specifics of config lookup, without disturbing the
large number of "simple" users (i.e., every other part of git).
The astute reader of this patch may notice that the logic for handling
config_exclusive_filename was taken out of git_config_early, but added
into git_config. This means that git_config_early will no longer respect
config_exclusive_filename. That's OK, because the only other caller of
git_config_early is check_repository_format_gently, but the only function
which sets config_exclusive_filename is cmd_config, which does not call
check_repository_format_gently (and if it did, it would have been a bug,
anyway, as we would be checking the repository format in the wrong file).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The other config-writing functions (git_config_set and
git_config_set_multivar) each have an -"in_file" version to
write a specific file. Let's add one for rename_section,
with the eventual goal of moving away from the magic
config_exclusive_filename global.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
