Some tests checked the "diff --stat" output when they do not have to,
which unnecessarily made things harder to verify under GETTEXT_POISON.
By Jonathan Nieder
* jn/diffstat-tests:
diffstat summary line varies by locale: miscellany
test: use numstat instead of diffstat in binary-diff test
test: use --numstat instead of --stat in "git stash show" tests
test: test cherry-pick functionality and output separately
test: modernize funny-names test style
test: use numstat instead of diffstat in funny-names test
test: use test_i18ncmp when checking --stat output
"git commit --author=$name" did not tell the name that was being recorded
in the resulting commit to hooks, even though it does do so when the end
user overrode the authorship via the "GIT_AUTHOR_NAME" environment
variable.
* jc/commit-hook-authorship:
commit: pass author/committer info to hooks
t7503: does pre-commit-hook learn authorship?
ident.c: add split_ident_line() to parse formatted ident line
Use API to read blob data in smaller chunks in more places to reduce the
memory footprint.
By Nguyễn Thái Ngọc Duy (6) and Junio C Hamano (1)
* nd/stream-more:
update-server-info: respect core.bigfilethreshold
fsck: use streaming API for writing lost-found blobs
show: use streaming API for showing blobs
parse_object: avoid putting whole blob in core
cat-file: use streaming API to print blobs
Add more large blob test cases
streaming: make streaming-write-entry to be more reusable
$COLUMNS must be unset to not interfere with the tests. The tests
already ignore the terminal size because output is redirected to a
file, but COLUMNS overrides terminal size detection and changes the
test output away from the standard 80.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Andrew Sayers noticed that the svn-fe | git fast-import pipeline
mishandles a subversion history that copies the root directory to a
sub-directory (e.g. doing `svn cp . trunk` to standardise your
layout). As David Barr explained, the bug arises when the following
command is sent to git fast-import:
'ls' SP ':1' SP LF
Instead of reading back what is at the root of r1, it unconditionally
reports the path as missing.
After sleeping on it, here are two patches for 'maint'. One plugs a
memory leak. The other ensures that trying to pass an empty path to
the 'ls' command results in an error message that can help the
frontend author instead of the silently broken conversion Andrew
found.
Then we can carefully add 'ls ""' support in 1.7.11.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIbBAABCAAGBQJPWtgPAAoJEN/Gce6zM/olpU4P92DnurNCuUOsCIOVvEHT7YC+
JdBou7wDKug2U0XH4yvTCglJZQ+zWpoobPoJlGu4c+RPWYGoUnOvc2jUmhFGD2r4
jLlNhq3Uob4CSdEA8JLz8IOvgW41kc2LuUsZrr19dC3eS/19U72NQpD5nA958wZw
xmvcu1DjhrsYHSdh4azg0Ccsp3PzesssCGJSckKoYpOZSlbznK3Dyn2KnLPZvAmx
fF6uyPAZXKsKDOyVUPczIQ+mitb5YhOa3eFDcZk/EBM1LUCqbE0qmFyPhFqtE2pP
f0BcG2MwXc6S8FIRTSkzxV3WP8Cl5+3Y3LX+aB9Y5Zl7Vx1LBdDEhEZS0DkJFW1u
c/64Ge89FD/mSKpJfu8iZdga+qalyF1u5fPPFvOKV3p6UO1ou1RuIVEDMUhMzPhi
244i7VnaPq232aMr8Jn4eAnpg+mZpOdDuqsJn4Q/BOpJ2D5UmKzja4LUZk2tkmgh
EzGYLbs//TZXKjeNGH1rBdbW9lO0fU8oGRaTKiRwWTQVAJ48hUlOYfMBsWvUnvI6
A5ar/iT8UthEc54OZIkBefjpFrwIXl3wG1iafDY8Z1rcnGsbH9MpNFLFxcoGQTBJ
9A6ZyqL7dEKg2SWfESXf93xkF/fFZYl+0jFm+VNuJUzkrsvoi4tkxs/3qxaE74Kb
zQtYbp/z+KWFh4eg830=
=wrup
-----END PGP SIGNATURE-----
Merge "two fixes for fast-import's 'ls' command" from Jonathan
Andrew Sayers noticed that the svn-fe | git fast-import pipeline
mishandles a subversion history that copies the root directory to a
sub-directory (e.g. doing `svn cp . trunk` to standardise your
layout). As David Barr explained, the bug arises when the following
command is sent to git fast-import:
'ls' SP ':1' SP LF
Instead of reading back what is at the root of r1, it unconditionally
reports the path as missing.
After sleeping on it, here are two patches for 'maint'. One plugs a
memory leak. The other ensures that trying to pass an empty path to
the 'ls' command results in an error message that can help the
frontend author instead of the silently broken conversion Andrew
found.
Then we can carefully add 'ls ""' support in 1.7.11.
* commit 'refs/pull-request-tags/jn/maint-fast-import-empty-ls':
fast-import: don't allow 'ls' of path with empty components
fast-import: leakfix for 'ls' of dirty trees
These changes are in the same spirit as the six patches that
precede them, but they haven't been split into individually
justifiable patches yet.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git's --stat output is intended for humans and since v1.7.9.2~13
(2012-02-01) varies by locale. The tests in this script using "apply
--stat" are meant to check two things:
- how binary file changes are accounted for and printed in
git's diffstat format
- that "git apply" can parse the various forms of binary diff
Split these two kinds of check into separate tests, and use --numstat
instead of --stat in the latter. This way, we lose less test coverage
when git is being run without writing its output in the C locale (for
example because GETTEXT_POISON is enabled) and there are fewer tests
to change if the --stat output needs to be tweaked again.
While at it, use commands separated by && that read and write to
temporary files in place of pipelines so segfaults and other failures
in the upstream of the processing pipeline don't get hidden.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git's diff --stat output is intended for human consumption and
since v1.7.9.2~13 (2012-02-01) varies by locale. Add a test checking
that git stash show defaults to --stat and tweak the rest of the
"stash show" tests that showed a diffstat to use numstat.
This way, there are fewer tests to tweak if the diffstat format
changes again. This also improves test coverage when running tests
with git configured not to write its output in the C locale (e.g.,
via GETTEXT_POISON=Yes).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since v1.7.3-rc0~26^2~9 (revert: report success when using option
--strategy, 2010-07-14), the cherry-pick-many-commits test checks the
format of output written to the terminal during a cherry-pick sequence
in addition to the functionality. There is no reason those have to
be checked in the same test, though, and it has some downsides:
- when progress output is broken, the test result does not convey
whether the functionality was also broken or not
- it is not immediately obvious when reading that these checks are
meant to prevent regressions in details of the output format and
are not just a roundabout way to check functional details like the
number of commits produced
- there is a temptation to include the same kind of output checking
for every new cherry-pick test, which would make future changes
to the output unnecessarily difficult
Put the tests from v1.7.3-rc0~26^2~9 in separate assertions, following
the principle "test one feature at a time".
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is one of the early tests, so it uses a style that by modern
standards can be hard to read. Tweak it to:
- clearly declare what assertion each test is designed to check
- mark tests that create state later tests will depend on with the
word "setup" so people writing or running tests know the others
can be skipped or reordered safely
- put commands that populate a file with expected output inside
the corresponding test stanza, so it is easier to see by eye
where each test begins and ends
- instead of pipelines, use commands that read and write a
temporary file, so bugs causing commands to segfault or produce
the wrong exit status can be caught.
More cosmetic changes:
- put the opening quote starting each test on the same line as the
test_expect_* invocation, and indent the commands in each test
with a single tab
- end the test early if the underlying filesystem cannot
accomodate the filenames we use, instead of marking all tests
with the same TABS_IN_FILENAMES prerequisite.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test script checks that git's plumbing commands quote filenames
with special characters like space, tab, and double-quote
appropriately in their input and output.
Since commit v1.7.9.2~13 (Use correct grammar in diffstat summary
line, 2012-02-01), the final "1 file changed, 1 insertion(+)" line
from diffstats is translatable, meaning tests that rely on exact "git
apply --stat" output have to be skipped when git is not configured to
produce output in the C locale (for example, when GETTEXT_POISON is
enabled). So:
- Tweak the three "git apply --stat" tests that check "git apply"'s
input parsing to use --numstat instead.
--numstat output is more reliable, does not vary with locale, and
is itself easier to parse. These tests are mainly about how "git
apply" parses its input so this should not result in much loss of
coverage.
- Add a new "apply --stat" test to check the quoting in --stat output
format.
This wins back a little of the test coverage lost with the patch
"test: use test_i18ncmp to check --stat output" when GETTEXT_POISON is
enabled.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ever since v1.7.9.2~13 (2012-02-01), git's diffstat-style summary line
produced by "git apply --stat", "git diff --stat", and "git commit"
varies by locale, producing test failures when GETTEXT_POISON is set.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was unclear what a test in t0204 wanted to check; it turns out
that it was only to observe an undefined behaviour of the system,
and did not anticipate one kind of reasonable error behaviour.
* jc/maint-undefined-i18n-observation-test:
t0204: clarify the "observe undefined behaviour" test
When "git config" diagnoses an error in a configuration file and
shows the line number for the offending line, it miscounted if the
error was at the end of line.
By Martin Stenberg
* ms/maint-config-error-at-eol-linecount:
config: report errors at the EOL with correct line number
Conflicts:
t/t1300-repo-config.sh
A section in a config file with a missing "]" reports the next line
as bad, same goes to a value with a missing end quote.
This happens because the error is not detected until the end of the
line, when line number is already increased. Fix this by decreasing
line number by one for these cases.
Signed-off-by: Martin Stenberg <martin@gnutiken.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When lying the author name via GIT_AUTHOR_NAME environment variable
to "git commit", the hooks run by the command saw it and could act
on the name that will be recorded in the final commit. When the user
uses the "--author" option from the command line, the command should
give the same information to the hook, and back when "git command"
was a scripted Porcelain, it did set the environment variable and
hooks can learn the author name from it.
However, when the command was reimplemented in C, the rewritten code
was not very faithful to the original, and hooks stopped getting the
authorship information given with "--author". Fix this by exporting
the necessary environment variables.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "--author" option is used to lie the authorship to "git commit"
command, hooks should learn the author name and email just like when
GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL environment variables are used
to lie the authorship. Test this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As the fast-import manual explains:
The value of <path> must be in canonical form. That is it must
not:
. contain an empty directory component (e.g. foo//bar is invalid),
. end with a directory separator (e.g. foo/ is invalid),
. start with a directory separator (e.g. /foo is invalid),
Unfortunately the "ls" command accepts these invalid syntaxes and
responds by declaring that the indicated path is missing. This is too
subtle and causes importers to silently misbehave; better to error out
so the operator knows what's happening.
The C, R, and M commands already error out for such paths.
Reported-by: Andrew Sayers <andrew-git@pileofstuff.org>
Analysis-by: David Barr <davidbarr@google.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
This test asks for an impossible conversion to the system by
preparing an UTF-8 translation with characters that cannot be
expressed in ISO-8859-1, and then asking the message shown in
ISO-8859-1. Even though the behaviour against such a request is
undefined, it may be interesting to see what the system does, and
the purpose of this test is to see if there are platforms that
exhibit behaviour that we haven't seen.
The original recognized two known modes of behaviour:
- the key used to query the message catalog ("TEST: Old English
Runes"), saying "I cannot do that i18n".
- impossible characters replaced with ASCII "?", saying "I punt".
but they were treated totally differently. The test simply issued
an informational message "Your system punts on this one" for the
first error mode, while it diagnosed the latter as "Your system is
good; you pass!".
It turns out that Mac OS X exhibits a third mode of error behaviour,
to spew out the raw value stored in the message catalog. The test
diagnosed this behaviour as "broken", but it is merely trying to do
its best to respond to an impossible request by saying "I punt" in a
way that is slightly different from the second one.
Update the offending test to make it clear what is (and is not)
being tested, update the code structure so that newly discovered
error mode can easily be added to it later, and reword the message
that comes from a failing case to clarify that it is not the system
that is broken when it fails, but merely that the behaviour is not
something we have seen.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'log -3000 (baseline)' test accidentally still used -1000 from an
earlier version.
Noticed-by: Lawrence Holding <Lawrence.Holding@cubic.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By Jens Lehmann (3) and Johannes Sixt (1)
* jl/maint-submodule-relative:
submodules: fix ambiguous absolute paths under Windows
submodules: refactor computation of relative gitdir path
submodules: always use a relative path from gitdir to work tree
submodules: always use a relative path to gitdir
The only bug right now is that $GIT_TEST_CMP is needed for test_cmp to
work.
However, we also export the three most important paths for tests:
TEST_DIRECTORY
TRASH_DIRECTORY
GIT_BUILD_DIR
Since they are available within test_expect_success, a future test
writer may expect them to also be defined in test_perf.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Loading it in the subshells still referred to $TEST_DIRECTORY/..,
which was only correct in preliminary versions of perf-lib.sh
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By Junio C Hamano (2) and Ramsay Jones (1)
* jc/pickaxe-ignore-case:
ctype.c: Fix a sparse warning
pickaxe: allow -i to search in patch case-insensitively
grep: use static trans-case table
This command indirectly calls check_sha1_signature() (add_info_ref ->
deref_tag -> parse_object -> ..) , which may put whole blob in memory
if the blob's size is under core.bigfilethreshold. As config is not
read, the threshold is always 512MB. Respect user settings here.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
New test cases list commands that should work when memory is
limited. All memory allocation functions (*) learn to reject any
allocation larger than $GIT_ALLOC_LIMIT if set.
(*) Not exactly all. Some places do not use x* functions, but
malloc/calloc directly, notably diff-delta. These code path should
never be run on large blobs.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By Junio C Hamano
* jc/maint-diff-patch-header:
diff -p: squelch "diff --git" header for stat-dirty paths
t4011: illustrate "diff-index -p" on stat-dirty paths
t4011: modernise style
By Thomas Rast
* tr/maint-bundle-boundary:
bundle: keep around names passed to add_pending_object()
t5510: ensure we stay in the toplevel test dir
t5510: refactor bundle->pack conversion
By Zbigniew Jędrzejewski-Szmek (8) and Junio C Hamano (1)
* zj/diff-stat-dyncol:
: This breaks tests. Perhaps it is not worth using the decimal-width stuff
: for this series, at least initially.
diff --stat: add config option to limit graph width
diff --stat: enable limiting of the graph part
diff --stat: add a test for output with COLUMNS=40
diff --stat: use a maximum of 5/8 for the filename part
merge --stat: use the full terminal width
log --stat: use the full terminal width
show --stat: use the full terminal width
diff --stat: use the full terminal width
diff --stat: tests for long filenames and big change counts
OS X's sed and grep would complain with (respectively)
sed: 1: "/^-/{p;q}": extra characters at the end of q command
grep: Regular expression too big
For sed, use an explicit ; to terminate the q command.
For grep, spell the "40 hex digits" explicitly in the regex, which
should be safe as other tests already use this and we haven't got
breakage reports on OS X about them.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
The current message is too long and at too low a level for anybody
to understand it if they don't know about the configuration format
already.
The text about setting up a remote is superfluous and doesn't help
understand or recover from the error that has happened. Show the
usage more prominently and explain how to set up the tracking
information. If there is only one remote, that name is used instead
of the generic <remote>.
Also simplify the message we print on detached HEAD to remove
unnecessary information which is better left for the documentation.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 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
* 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
* 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
In module_clone() the rel_gitdir variable was computed differently when
"git rev-parse --git-dir" returned a relative path than when it returned
an absolute path. This is not optimal, as different code paths are used
depending on the return value of that command.
Fix that by reusing the differing path components computed for setting the
core.worktree config setting, which leaves a single code path for setting
both instead of having three and makes the code much shorter.
This also fixes the bug that in the computation of how many directories
have to be traversed up to hit the root directory of the submodule the
name of the submodule was used where the path should have been used. This
lead to problems after renaming submodules into another directory level.
Even though the "(cd $somewhere && pwd)" approach breaks the flexibility
of symlinks, that is no issue here as we have to have one relative path
pointing from the work tree to the gitdir and another pointing back, which
will never work anyway when a symlink along one of those paths is changed
because the directory it points to was moved.
Also add a test moving a submodule into a deeper directory to catch any
future breakage here and to document what has to be done when a submodule
needs to be moved until git mv learns to do that. Simply moving it to the
new location doesn't work, as the core.worktree and possibly the gitfile
setting too will be wrong. So it has to be removed from filesystem and
index, then the new location has to be added into the index and the
.gitmodules file has to be updated. After that a git submodule update will
check out the submodule at the new location.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since recently a submodule with name <name> has its git directory in the
.git/modules/<name> directory of the superproject while the work tree
contains a gitfile pointing there. To make that work the git directory has
the core.worktree configuration set in its config file to point back to
the work tree.
That core.worktree is an absolute path set by the initial clone of the
submodule. A relative path is preferable here because it allows the
superproject to be moved around without invalidating that setting, so
compute and set that relative path after cloning or reactivating the
submodule.
This also fixes a bug when moving a submodule around inside the
superproject, as the current code forgot to update the setting to the new
submodule work tree location.
Enhance t7400 to ensure that future versions won't re-add absolute paths
by accident and that moving a superproject won't break submodules.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since recently a submodule with name <name> has its git directory in the
.git/modules/<name> directory of the superproject while the work tree
contains a gitfile pointing there. When the submodule git directory needs
to be cloned because it is not found in .git/modules/<name> the clone
command will write an absolute path into the gitfile. When no clone is
necessary the git directory will be reactivated by the git-submodule.sh
script by writing a relative path into the gitfile.
This is inconsistent, as the behavior depends on the submodule having been
cloned before into the .git/modules of the superproject. A relative path
is preferable here because it allows the superproject to be moved around
without invalidating the gitfile. We do that by always writing the
relative path into the gitfile, which overwrites the absolute path the
clone command may have written there.
This is only the first step to make superprojects movable again like they
were before the separate-git-dir approach was introduced. The second step
is to use a relative path in core.worktree too.
Enhance t7400 to ensure that future versions won't re-add absolute paths
by accident.
While at it also replace an if/else construct evaluating the presence
of the 'reference' option with a single line of bash code.
Reported-by: Antony Male <antony.male@gmail.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
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>
Prepare expected output inside test_expect_success that uses it.
Also remove excess blank lines.
Signed-off-by: Tom Grennan <tmgrennan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
