* tr/perftest:
Add a performance test for git-grep
Introduce a performance testing framework
Move the user-facing test library to test-lib-functions.sh
merge: do not trust fstat(2) too much when checking interactiveness
The heuristic used by "git merge" to decide if it automatically gives an
editor upon clean automerge is to see if the standard input and the
standard output is the same device and is a tty, we are in an interactive
session. "The same device" test was done by comparing fstat(2) result on
the two file descriptors (and they must match), and we asked isatty() only
for the standard input (we insist that they are the same device and there
is no point asking tty-ness of the standard output).
The stat(2) emulation in the Windows port however does not give a usable
value in the st_ino field, so even if the standard output is connected to
something different from the standard input, "The same device" test may
incorrectly return true. To accomodate it, add another isatty() check for
the standard output stream as well.
Reported-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was indeed not obvious for new contributors to find this document in
the source tree, since there were no reference to it outside the
Documentation/ directory.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This was part of the "branch description" feature in the larger
"help people communicate better during their pull based workflow"
topic, but was never documented.
Merge branch 'master' of git://bogomips.org/git-svn
* 'master' of git://bogomips.org/git-svn:
git-svn.perl: fix a false-positive in the "already exists" test
git-svn.perl: perform deletions before anything else
git-svn: Fix time zone in --localtime
git-svn: un-break "git svn rebase" when log.abbrevCommit=true
git-svn: remove redundant porcelain option to rev-list
completion: add --interactive option to git svn dcommit
* 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
Merge branch 'jk/grep-binary-attribute' into maint
* 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
Merge branch 'nd/find-pack-entry-recent-cache-invalidation' into maint
* 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
git-svn.perl: fix a false-positive in the "already exists" test
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>
git-svn.perl: perform deletions before anything else
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>
git-svn: un-break "git svn rebase" when log.abbrevCommit=true
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>
git-svn: remove redundant porcelain option to rev-list
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>
completion: Allow dash as the first character for __git_ps1
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 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>
gitweb: Fix 'grep' search for multiple matches in file
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>
gitweb: Fix "heads" view when there is no current branch
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>
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>
The line was extended in 2dd8c3 ('git: add --info-path and --man-path
options'), and the formatted man output stopped fitting into the 80
column window.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
make lineno_width() from blame reusable for others
builtin/blame.c has a helper function to compute how many columns
we need to show a line-number, whose implementation is reusable as
a more generic helper function to count the number of columns
necessary to show any cardinal number.
Rename it to decimal_width(), move it to pager.c and export it for
use by future callers.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --stat: show bars of same length for paths with same amount of changes
When commit 3ed74e6 (diff --stat: ensure at least one '-' for deletions,
and one '+' for additions, 2006-09-28) improved the output for files with
tiny modifications, we accidentally broke the logic to ensure that two
equal sized changes are shown with the bars of the same length, even when
rounding errors exist.
Compute the length of the graph bars, using the same "non-zero changes is
shown with at least one column" scaling logic, but by scaling the sum of
additions and deletions to come up with the total length of the bar (this
ensures that two equal sized changes result in bars of the same length),
and then scaling the smaller of the additions or deletions. The other side
is computed as the difference between the two.
This makes the apportioning between additions and deletions less accurate
due to rounding errors, but it is much less noticeable than two files with
the same amount of change showing bars of different length.
* 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/pack-objects-parseopt:
pack-objects: convert to use parse_options()
pack-objects: remove bogus comment
pack-objects: do not accept "--index-version=version,"
* mh/war-on-extra-refs:
refs: remove the extra_refs API
clone: do not add alternate references to extra_refs
everything_local(): mark alternate refs as complete
fetch-pack.c: inline insert_alternate_refs()
fetch-pack.c: rename some parameters from "path" to "refname"
clone.c: move more code into the "if (refs)" conditional
t5700: document a failure of alternates to affect fetch
* jk/maint-tag-show-fixes:
tag: do not show non-tag contents with "-n"
tag: die when listing missing or corrupt objects
tag: fix output of "tag -n" when errors occur
Currently we only bother highlighting single-line hunks. The
rationale was that the purpose of highlighting is to point
out small changes between two similar lines that are
otherwise hard to see. However, that meant we missed similar
cases where two lines were changed together, like:
Each of those changes is simple, and would benefit from
highlighting (the "obj->" parts in this case).
This patch considers whole hunks at a time. For now, we
consider only the case where the hunk has the same number of
removed and added lines, and assume that the lines from each
segment correspond one-to-one. While this is just a
heuristic, in practice it seems to generate sensible
results (especially because we now omit highlighting on
completely-changed lines, so when our heuristic is wrong, we
tend to avoid highlighting at all).
Based on an original idea and implementation by Michał
Kiedrowicz.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff-highlight: refactor to prepare for multi-line hunks
The current code structure assumes that we will only look at
a pair of lines at any given time, and that the end result
should always be to output that pair. However, we want to
eventually handle multi-line hunks, which will involve
collating pairs of removed/added lines. Let's refactor the
code to return highlighted pairs instead of printing them.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
we end up highlighting the entirety of both lines (since the
whole thing is changed). But the point of diff highlighting
is to pinpoint the specific change in a pair of lines that
are mostly identical. In this case, the highlighting is just
noise, since there is nothing to pinpoint, and we are better
off doing nothing.
The implementation looks for "interesting" pairs by checking
to see whether they actually have a matching prefix or
suffix that does not simply consist of colorization and
whitespace. However, the implementation makes it easy to
plug in other heuristics, too, like:
1. Depending on the source material, the set of "boring"
characters could be tweaked to include language-specific
stuff (like braces or semicolons for C).
2. Instead of saying "an interesting line has at least one
character of prefix or suffix", we could require that
less than N percent of the line be highlighted.
The simple "ignore whitespace, and highlight if there are
any matched characters" implemented by this patch seems to
give good results on git.git. I'll leave experimentation
with other heuristics to somebody who has a dataset that
does not look good with the current code.
Based on an original idea and implementation by Michał
Kiedrowicz.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
pager: find out the terminal width before spawning the pager
term_columns() checks for terminal width via ioctl(2) on the standard
output, but we spawn the pager too early for this check to be useful.
The effect of this buglet can be observed by opening a wide terminal and
running "git -p help --all", which still shows 80-column output, while
"git help --all" uses the full terminal width. Run the check before we
spawn the pager to fix this.
While at it, move term_columns() to pager.c and export it from cache.h so
that callers other than the help subsystem can use it.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Receive runs rev-list --verify-objects in order to detect missing
objects. However, such errors are ignored and overridden later.
Instead, consequently ignore all update commands for which an error has
already been detected.
Some tests in t5504 are obsoleted by this change, because invalid
objects are detected even if fsck is not enabled. Instead, they now test
for different error messages depending on whether or not fsck is turned
on. A better fix would be to force a corruption that will be detected by
fsck but not by rev-list.
Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default, progress output is disabled if stderr is not a terminal.
The --progress option can be used to force progress output anyways.
Conversely, --no-progress does not force progress output. In particular,
if stderr is a terminal, progress output is enabled.
This is unintuitive. Change --no-progress to force output off.
Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git rev-list passes rev_list_info, not rev_list objects. Without this
fix, rev-list enables or disables the --verify-objects option depending
on a read from an undefined memory location.
Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>