8c912ee (teach --histogram to diff, 2011-07-12) claimed histogram diff
was faster than both Myers and patience.
We have since incorporated a performance testing framework, so add a
test that compares the various diff tasks performed in a real 'log -p'
workload. This does indeed show that histogram diff slightly beats
Myers, while patience is much slower than the others.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
fast-import: zero all of 'struct tag' to silence valgrind
When running t9300, valgrind (correctly) complains about an
uninitialized value in write_crash_report:
==2971== Use of uninitialised value of size 8
==2971== at 0x4164F4: sha1_to_hex (hex.c:70)
==2971== by 0x4073E4: die_nicely (fast-import.c:468)
==2971== by 0x43284C: die (usage.c:86)
==2971== by 0x40420D: main (fast-import.c:2731)
==2971== Uninitialised value was created by a heap allocation
==2971== at 0x4C29B3D: malloc (vg_replace_malloc.c:263)
==2971== by 0x433645: xmalloc (wrapper.c:35)
==2971== by 0x405DF5: pool_alloc (fast-import.c:619)
==2971== by 0x407755: pool_calloc.constprop.14 (fast-import.c:634)
==2971== by 0x403F33: main (fast-import.c:3324)
Fix this by zeroing all of the 'struct tag'. We would only need to
zero out the 'sha1' field, but this way seems more future-proof.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/gitweb-hilite-regions:
gitweb: Highlight matched part of shortened project description
gitweb: Highlight matched part of project description when searching projects
gitweb: Highlight matched part of project name when searching projects
gitweb: Introduce esc_html_match_hl and esc_html_hl_regions
* maint:
Update draft release notes to 1.7.9.3 for the last time
http.proxy: also mention https_proxy and all_proxy
t0300: work around bug in dash 0.5.6
t5512 (ls-remote): modernize style
tests: fix spurious error when run directly with Solaris /usr/xpg4/bin/sh
Merge branch 'jk/maint-avoid-streaming-filtered-contents' into maint
* jk/maint-avoid-streaming-filtered-contents:
do not stream large files to pack when filters are in use
teach dry-run convert_to_git not to require a src buffer
teach convert_to_git a "dry run" mode
Merge branch 'tr/maint-bundle-long-subject' into maint
* tr/maint-bundle-long-subject:
t5704: match tests to modern style
strbuf: improve strbuf_get*line documentation
bundle: use a strbuf to scan the log for boundary commits
bundle: put strbuf_readline_fd in strbuf.c with adjustments
http.proxy: also mention https_proxy and all_proxy
The current wording of the http.proxy documentation suggests that
http_proxy is somehow equivalent to http.proxy. However, while
http.proxy (by the means of curl's CURLOPT_PROXY option) overrides the
proxy for both HTTP and HTTPS protocols, the http_proxy environment
variable is used only for HTTP. But since the docs mention only
http_proxy, a user might expect it to apply to all HTTP-like protocols.
Avoid any such misunderstanding by explicitly mentioning https_proxy and
all_proxy as well.
Also replace linkgit:curl[1] with a literal 'curl(1)', because the
former gets translated to a dead link in the HTML pages.
Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The user specifies a long option but forgets to type the second
leading dash, we currently detect and report that fact if its first
letter is a valid short option. This is done for safety, to avoid
ambiguity between short options (and their arguments) and a long
option with a missing dash.
This diagnostic message is also helpful for long options whose first
letter is not a valid short option, however. Print it in that case,
too, as a courtesy.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The construct 'while IFS== read' makes dash 0.5.6 execute
read without changing IFS, which results in test breakages
all over the place in t0300. Neither dash 0.5.5.1 and older
nor dash 0.5.7 and newer are affected: The problem was
introduded resp. fixed by the commits
55c46b7 ([BUILTIN] Honor tab as IFS whitespace when
splitting fields in readcmd, 2009-08-11)
1d806ac ([VAR] Do not poplocalvars prematurely on regular
utilities, 2010-05-27)
in http://git.kernel.org/?p=utils/dash/dash.git
Putting 'IFS==' before that line makes all versions of dash
work.
This looks like a dash bug, not a misinterpretation of the
standard. However, it's worth working around for two
reasons. One, this version of dash was released in Fedora
14-16, so the bug is found in the wild. And two, at least
one other shell, Solaris /bin/sh, choked on this by
persisting IFS after the read invocation. That is not a
shell we usually care about, and I think this use of IFS is
acceptable by POSIX (which allows other behavior near
"special builtins", but "read" is not one of those). But it
seems that this may be a subtle, not-well-tested case for
some shells. Given that the workaround is so simple, it's
worth just being defensive.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Fix passing parameters to git_project_search_form
The git_project_search_form() subroutine, introduced in a1e1b2d
(gitweb: improve usability of projects search form, 2012-01-31) didn't
get its arguments from caller correctly. Gitweb worked correctly
thanks to sticky-ness of form fields in CGI.pm... but it make UTF-8
fix for project search not working.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
tests: fix spurious error when run directly with Solaris /usr/xpg4/bin/sh
If any test script is run directly with Solaris 10 /usr/xpg4/bin/sh or
/bin/ksh, it fails spuriously with a message like:
t0000-basic.sh[31]: unset: bad argument count
This happens because those shells bail out when encountering a call to
"unset" with no arguments, and such unset call could take place in
'test-lib.sh'. Fix that issue, and add a proper comment to ensure we
don't regress in this respect.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: do not assume that n > 1 in <rev>~$n
We explained <rev>~<n> as <n>th generation grand-parent, but a reader got
confused by the "grand-" part when <n> is 1.
Reword it with "ancestor"; with the "generation" and "following only the
first parents" around there, what we try to describe should be clear
enough now.
Noticed-by: Luke Diamand <luke@diamand.org> Helped-by: Thomas Rast <trast@inf.ethz.ch> Helped-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* l10n:
Update l10n guide: change the repository URL, etc
l10n: leave leading space unchanged for zh_CN.po
Update l10n guide
l10n: update Chinese translation to the new git.po
l10n: Update git.pot (12 new messages)
l10n: fast-forward here is ff-only merge, not push
l10n: update zh_CN translation for "Fetching %s"
l10n: po for zh_CN
l10n: initial git.pot for 1.7.10 upcoming release
Host the l10n coordinator repository in a dedicated github organization
account "git-l10n", so that the team may have a more permanent home.
Also add a hint about reference of TEAMS file for l10n contributors.
Update TEAMS file with new zh_CN l10n team members and a repository URL.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
fsck: --no-dangling omits "dangling object" information
The default output from "fsck" is often overwhelmed by informational
message on dangling objects, especially if you do not repack often, and a
real error can easily be buried.
Add "--no-dangling" option to omit them, and update the user manual to
demonstrate its use.
Based on a patch by Clemens Buchacher, but reverted the part to change
the default to --no-dangling, which is unsuitable for the first patch.
The usual three-step procedure to break the backward compatibility over
time needs to happen on top of this, if we were to go in that direction.
Documentation: use {asterisk} in rev-list-options.txt when needed
Text between two '*' is emphasized in AsciiDoc and makes explanations in
rev-list-options.txt on glob-related options very confusing, as the
rendered text would be missing two asterisks and the text between them
would be emphasized instead.
Use '{asterisk}' where needed to make them show up as asterisks in the
rendered text.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
PARSE_OPT_NEGHELP is confusing because short options defined with that
flag do the opposite of what the helptext says. It is also not needed
anymore now that options starting with no- can be negated by removing
that prefix. Convert its only two users to OPT_NEGBIT() and OPT_BOOL()
and then remove support for PARSE_OPT_NEGHELP.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using regexp search ('sr' parameter / $search_use_regexp variable
is true), check first that regexp is valid.
Without this patch we would get an error from Perl during search (if
searching is performed by gitweb), or highlighting matches substring
(if applicable), if user provided invalid regexp... which means broken
HTML, with error page (including HTTP headers) generated after gitweb
already produced some output.
Add test that illustrates such error: for example for regexp "*\.git"
we would get the following error:
Quantifier follows nothing in regex; marked by <-- HERE in m/* <-- HERE \.git/
at /var/www/cgi-bin/gitweb.cgi line 3084.
Reported-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When --quiet is specified, finish_object() is called instead of
show_object(). The latter is in charge of --verify-objects and
will be skipped if --quiet is specified.
Move the code up to finish_object(). Also pass the quiet flag along
and make it always call show_* functions to avoid similar problems in
future.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since c99f069 (bisect--helper: remove "--next-vars" option as it is
now useless - 2009-04-21), this flag has always been off. Remove the
flag and all related code.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
symbolic-ref --short: abbreviate the output unambiguously
It can be helpful to resolve a symbolic ref and output the result in a
shortened form, such as for use in shell prompts. Add a "--short" option
to do so.
Signed-off-by: Jan Krüger <jk@jk.gs> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Update draft release notes to 1.7.9.3
CodingGuidelines: do not use 'which' in shell scripts
CodingGuidelines: Add a note about spaces after redirection
post-receive-email: match up $LOGBEGIN..$LOGEND pairs correctly
post-receive-email: remove unused variable
CodingGuidelines: do not use 'which' in shell scripts
During the code review of a recent patch, it was noted that shell scripts
must not use 'which $cmd' to check the availability of the command $cmd.
The output of the command is not machine parseable and its exit code is
not reliable across platforms.
It is better to use 'type' to accomplish this task.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'git difftool' allows the user to view diffs using an external tool.
It runs a separate instance of the tool for each file in the diff. This
makes it tedious to review changes spanning multiple files.
The 'git-diffall' script instead prepares temporary directories with the
files to be compared and launches a single instance of the external diff
tool to view them (i.e. a directory diff).
The 'diff.tool' or 'merge.tool' configuration variable is used to specify
which external tool is used.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-p4: missing she-bang line in t9804 confuses prove
Without the magic line, prove shows lots and lots of errors:
% prove ./t9804-git-p4-label.sh
./t9804-git-p4-label.sh .. syntax error at ./t9804-git-p4-label.sh line 3, near ". ."
...
When #!/bin/sh is added, tests are skipped (I have no p4d).
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier, fba4f1 (grep -P: Fix matching ^ and $) fixed an ancient bug. Add
some tests to protect the change from future breakages; a slightly broken
version of this was a part of the originally submitted patch.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
print_ref_list looks up the merge_filter_ref and assumes that a valid
pointer is returned. When the object doesn't exist, it tries to
dereference a NULL pointer. This can be the case when git branch
--merged is given an argument that isn't a valid commit name.
Check whether the lookup returns a NULL pointer and die with an error
if it does. Add a test, while we're at it.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option was already shown in -h output, so it should be documented
in the man page.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Suggested-by: David A. Greene <greened@obbligato.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/gitweb-search-optim:
gitweb: Faster project search
gitweb: Option for filling only specified info in fill_project_list_info
gitweb: Refactor checking if part of project info need filling
* tr/maint-bundle-long-subject:
t5704: match tests to modern style
strbuf: improve strbuf_get*line documentation
bundle: use a strbuf to scan the log for boundary commits
bundle: put strbuf_readline_fd in strbuf.c with adjustments
* fc/push-prune:
push: add '--prune' option
remote: refactor code into alloc_delete_ref()
remote: reorganize check_pattern_match()
remote: use a local variable in match_push_refs()
* jk/maint-avoid-streaming-filtered-contents:
do not stream large files to pack when filters are in use
teach dry-run convert_to_git not to require a src buffer
teach convert_to_git a "dry run" mode
gitweb: Highlight matched part of shortened project description
Previous commit make gitweb use esc_html_match_hl() to mark match in
the _whole_ description of a project when searching projects.
This commit makes gitweb highlight match in _shortened_ description,
based on match in whole description, using esc_html_match_hl_chopped()
subroutine.
If match is in removed (chopped) part, even partially, then trailing
"... " is highlighted.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Highlight matched part of project description when searching projects
Use esc_html_match_hl() from earlier commit to mark match in the
_whole_ description when searching projects.
Currently, with this commit, when searching projects there is always
shown full description of a project, and not a shortened one (like for
ordinary projects list view), even if the match is on project name and
not project description. Because we always show full description of a
project, and not possibly shortened name, there is no need for having
full description on mouseover via title attribute.
Showing full description when there is match on it is useful to avoid
situation where match is in shortened, invisible part. On the other
hand that makes project search different than projects list view; also
there can be problems with overly-long project descriptions.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Highlight matched part of project name when searching projects
Use esc_html_match_hl() introduced in previous commit to escape HTML
and mark match, using span element with 'match' class. Currently only
the 'path' part (i.e. the project name) is highlighted; match might be
on the project description. Highlighting match in description is left
for next commit.
The code makes use of the fact that defined $search_regexp means that
there was search going on.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Introduce esc_html_match_hl and esc_html_hl_regions
The esc_html_match_hl() subroutine added in this commit will be used
to highlight *all* matches of given regexp, using 'match' class.
Ultimately it is to be used in all match highlighting, starting
with project search, which does not have it yet.
It uses the esc_html_hl_regions() subroutine, which is meant to
highlight in a given string a list of regions (given as a list of
[ beg, end ] pairs of positions in string), using HTML <span> element
with given class. It could probably be used in other places that
do highlighting of part of ready line, like highlighting of changes
in a diff (diff refinement highlighting).
Implementation and enhancement notes:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Currently esc_html_hl_regions() subroutine doesn't accept any
parameters, like esc_html() does. We might want for example to
pass nbsp=>1 to it.
It can easily be done with the following code:
my %opts = grep { ref($_) ne "ARRAY" } @sel;
@sel = grep { ref($_) eq "ARRAY" } @sel;
This allow adding parameters after or before regions, e.g.:
* esc_html_hl_regions() escapes like esc_html(); if we wanted to
highlight with esc_path(), we could pass subroutine reference
to now named esc_gen_hl_regions().
* Alternate solution for highlighting region of a string would be to
use the idea that strings are to be HTML-escaped, and references to
scalars are HTML (like in the idea for generic committags).
This would require modifying gitweb code or esc_html to get list of
fragments, e.g.:
It looks like commit 99fb6e04 (pack-objects: convert to use
parse_options(), 2012-02-01) moved the #ifdef NO_PTHREDS around but
hasn't noticed that the 'arg' variable no longer is available.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Acked-by: Nguyen Thai Ngoc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Document accumulated fixes since 1.7.9.2
Git 1.7.8.5
grep -P: Fix matching ^ and $
am: don't infloop for an empty input file
rebase -m: only call "notes copy" when rewritten exists and is non-empty
git-p4: remove bash-ism in t9800
git-p4: remove bash-ism in t9809
git-p4: fix submit regression with clientSpec and subdir clone
git-p4: set useClientSpec variable on initial clone
Makefile: add thread-utils.h to LIB_H
When "git grep" is run with -P/--perl-regexp, it doesn't match ^ and $ at
the beginning/end of the line. This is because PCRE normally matches ^
and $ at the beginning/end of the whole text, not for each line, and "git
grep" passes a large chunk of text (possibly containing many lines) to
pcre_exec() and then splits the text into lines.
This makes "git grep -P" behave differently from "git grep -E" and also
from "grep -P" and "pcregrep":
$ cat file
a
b
$ git grep --no-index -P '^ ' file
$ git grep --no-index -E '^ ' file
file: b
$ grep -c -P '^ ' file
b
$ pcregrep -c '^ ' file
b
Reported-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-am.sh's check_patch_format function would attempt to preview
the patch to guess its format, but would go into an infinite loop
when the patch file happened to be empty. The solution: exit the
loop when "read" fails, not when the line var, "$l1" becomes empty.
Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>