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>
The auto detection was testing if a fixed string that is known to be
non-empty is empty by mistake.
* jc/i18n-shell-script-gettext:
i18n: fix auto detection of gettext scheme for shell scripts
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
We have had these options as harmless no-op for more than 3 years without
officially deprecating them. Let's announce the deprecation and start
warning against their use, but without failing the command just not yet,
so that we can later repurpose the option if we want to in the future.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git tag -s" honored "gpg.program" configuration variable since
1.7.9, but "git tag -v" and "git verify-tag" didn't.
By Alex Zepeda
* az/verify-tag-use-gpg-config:
verify-tag: Parse GPG configuration options.
"git bundle" did not record boundary commits correctly when there
are many of them.
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
"git diff-index" and its friends at the plumbing level showed the
"diff --git" header and nothing else for a path whose cached stat
info is dirty without actual difference when asked to produce a
patch. This was a longstanding bug that we could have fixed long
time ago.
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
"gitweb" did use quotemeta() to prepare search string when asked to
do a fixed-string project search, but did not use it by mistake and
used the user-supplied string instead.
By Jakub Narebski
* jn/maint-do-not-match-with-unsanitized-searchtext:
gitweb: Fix fixed string (non-regexp) project search
The code to synthesize the fake ancestor tree used by 3-way merge
fallback in "git am" was not prepared to read a patch created with
a non-standard -p<num> value.
* jc/am-3-nonstandard-popt:
test: "am -3" can accept non-standard -p<num>
am -3: allow nonstandard -p<num> option
The --binary option to git-apply has been a no-op since 2b6eef9 (Make
apply --binary a no-op., 2006-09-06) and was deprecated in cb3a160
(git-am: ignore --binary option, 2008-08-09).
We could remove it outright, but let's be nice to people who still
have scripts saying 'git am -b' (if they exist) and tell them the
reason for the sudden failure.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A new code added by ad17ea7 (add a Makefile switch to avoid gettext
translation in shell scripts, 2012-01-23) tried to optionally force
a gettext scheme to "fallthrough", but ended up forcing it to everybody.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
Updates to localized messages for zn_CN and sv locales.
via Jiang Xin
* https://github.com/git-l10n/git-po:
l10n: Improve zh_CN translation for msg "not something we can merge"
l10n: Improve zh_CN trans for msg that cannot fast-forward
l10n: Update zh_CN translation for 1.7.10-rc0
Update Swedish translation (732t0f0u).
po/sv.po: add Swedish translation
l10n: Update git.pot (1 new message)
l10n: Update zh_CN translation for 1.7.9.2
l10n: Improve commit msg for zh_CN translation
l10n: Improve zh_CN translation for msg that make empty commit when amend.
l10n: Improve zh_CN translation for empty cherry-pick msg.
l10n: Improve zh_CN translation for msg about branch deletion deny
l10n: Improve zh_CN translation for lines insertion and deletion.
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>
The commit formatting logic format_person_part() in pretty.c
implements the logic to split an author/committer ident line into
its parts, intermixed with logic to compute its output using these
piece it computes.
Separate the former out to a helper function split_ident_line() so
that other codepath can use the same logic, and rewrite the function
using the helper function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the Exporter invocation in Git::I18N to be compatible with
5.8.0 to 5.8.2 inclusive. Before Exporter 5.57 (released with 5.8.3)
Exporter didn't export the 'import' subroutine.
Reported-by: Tom G. Christensen <tgc@statsbiblioteket.dk>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
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>
When the chosen directory has changed since it was last written to
pack, "tree_content_get" makes a deep copy of its content to scribble
on while computing the tree name, which we forgot to free.
This leak has been present since the 'ls' command was introduced in
v1.7.5-rc0~3^2~33 (fast-import: add 'ls' command, 2010-12-02).
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>
On a Solaris 10 system with Solaris make installed as '/usr/xpg4/bin/make',
GNU make installed as '/usr/local/bin/make', and with '/usr/local/bin'
appearing in $PATH *before* '/usr/xpg4/bin', I was seeing errors like this
upon invoking "make all":
Usage : make [ -f makefile ][ -K statefile ]...
make: Fatal error: Unknown option `-C'
This happenes because the Git's Makefile, when running on Solaris,
automatically "sanitizes" $PATH by prepending '/usr/xpg6/bin' and
'/usr/xpg4/bin' to it in order to avoid using non-POSIX /bin/sh from
being used. In the setup described above, however, this has an
unintended consequence of forcing the use of Solaris make in recursive
make invocations -- even if the $(MAKE) macro is being correctly used in
them!
When building without using the autoconf machinery, this can be solved
by overriding $(SANE_TOOL_PATH). Teach the autoconf machinery to also
allow users of ./configure to override it from the command line with a
new --with-sane-tool-path option.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
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>
This adds the 'remaining' command to the documentation of
'git rerere'. This command was added in ac49f5ca (Feb 16 2011;
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>) but
it was never documented.
Touch up the other rerere commands to reduce noise.
First noticed by Vincent van Ravesteijn.
Signed-off-by: Phil Hord <phil.hord@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Modify verify-tag to load relevant GPG variables from the git
configuratio file. This allows git tag -v to use an alternative
GPG binary in the same way that git tag -s does.
Signed-off-by: Alex Zepeda <alex@inferiorhumanorgans.com>
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
By Vincent van Ravesteijn
* vr/branch-doc:
Documentation/git-branch: add default for --contains
Documentation/git-branch: fix a typo
Documentation/git-branch: cleanups
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>
This update includes a replay of some review fixes from the initial
translation run in 2010, which I cannot find having committed anywhere.
Add myself to the po/TEAMS file as well.
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
Update file 'po/git.pot' to v1.7.10-rc0:
* Add 1 new l10n string in the new generated "git.pot" file at line:
191
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
In the while loop inside apply_patch, patch and fragments are
dynamically allocated with a calloc. However, only unused patches
are actually freed and the rest are left to leak. Since a list is
actively built up consisting of the used patches, they can simply be
iterated and freed at the end of the function.
In addition, the text in fragments were not freed, primarily because
they mostly point into a patch text that is freed as a whole. But
there are some cases where new piece of memory is allocated and
pointed by a fragment (namely, when handling a binary patch).
Introduce a free_patch bitfield to mark each fragment if its text
needs to be freed, and free patches, fragments and fragment text
that need to be freed when we are done with the input.
Signed-off-by: Jared Hance <jaredhance@gmail.com>
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
Both git-prune and git-repack (and thus, git-gc) try to rmdir while
holding a DIR* handle on the directory. This can leave dangling
empty directories in the .git/objects on platforms where directory
cannot be removed while they are open.
First call closedir() and then rmdir(); that is more logical ordering.
Reported-by: John Chen <john0312@gmail.com>
Reported-by: Stefan Naewe <stefan.naewe@gmail.com>
Signed-off-by: Karsten Blees <blees@dcon.de>
Improved-and-Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
