Commit graph

8 commits

Author SHA1 Message Date
Ævar Arnfjörð Bjarmason
e75d2f7f73 revisions API: have release_revisions() release "filter"
Extend the the release_revisions() function so that it frees the
"filter" in the "struct rev_info". This in combination with a
preceding change to free "cmdline" means that we can mark another set
of tests as passing under "TEST_PASSES_SANITIZE_LEAK=true".

The "filter" member was added recently in ffaa137f64 (revision: put
object filter into struct rev_info, 2022-03-09), and this fixes leaks
intruded in the subsequent leak 7940941de1 (pack-objects: use
rev.filter when possible, 2022-03-09) and 105c6f14ad (bundle: parse
filter capability, 2022-03-09).

The "builtin/pack-objects.c" leak in 7940941de1 was effectively with
us already, but the variable was referred to by a "static" file-scoped
variable. The "bundle.c " leak in 105c6f14ad was newly introduced
with the new "filter" feature for bundles.

The "t5600-clone-fail-cleanup.sh" change here to add
"TEST_PASSES_SANITIZE_LEAK=true" is one of the cases where
run-command.c in not carrying the abort() exit code upwards would have
had that test passing before, but now it *actually* passes[1]. We
should fix the lack of 1=1 mapping of SANITIZE=leak testing to actual
leaks some other time, but it's an existing edge case, let's just mark
the really-passing test as passing for now.

1. https://lore.kernel.org/git/220303.86fsnz5o9w.gmgdl@evledraar.gmail.com/

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13 23:56:09 -07:00
Junio C Hamano
7720c33f63 Git 2.7.6
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABCAAGBQJZflNxAAoJELC16IaWr+bLpSsQAIT1s4c/uKAXJBw8CegM4SP1
 SeB5NMnjz7VVtBsdXKPy6fVXBHCjffON/MvNXcXwGqzx3lh6SiMAVNjYknBkQcKN
 b639dD9HEEBRFf62a+QAyRYbFeg0NONVydB25s7RfR57HUNxFibaJDT5SoymO0/5
 YCdmMENuvijvCYcwyb3MSjAKCkwDDErPzyI4NZ2YZpC7IG46Uoxq8BCdHpKhXa5I
 3TNEDruBAd/UJCIQiMW1HP3OMQXzXmCTL5i4QSr/uloO1kNzkWgCZDkkFrSGFPdx
 UeTRXOM0r5QdFXZC36zZNoL5ELflgzrYFSerj6VkCAbiG4FAWL+43CCxuUcq5OkZ
 JsTYObieBMFiaowTn9hKo3ix1xDSjR2+p0bfZbOPy5jMB85oegnjV3Rp/eBoXsDm
 h4qo+5kv0h8H2wKdxcBfVg6LkpBZGsvEOveAtWZIcFIVIOyULj9UAsnTwOotwQiL
 NHO4J2fJhcvSYUj6oGB3SpabKZfcbVXRE2fzZq+3+Mt4DdzSdSmx5CEJfUmxN7sQ
 YLb8UKSr2vv03YfKRghCGxqjOcmQL5vY79O8+QSN3cCDFFAwxzNYaGeHJ+/chvh2
 NySOkUf/uA7H1xQiZmJI1mfwQvi527MEzblCPDButm6n8ty6QyWOQ+kQYzcW5jjI
 kPWdqc5pCZQ+Q+q6lQc0
 =rNay
 -----END PGP SIGNATURE-----

Merge tag 'v2.7.6' into maint-2.8

Git 2.7.6
2017-07-30 14:46:43 -07:00
Jeff King
3be4cf09cd connect: reject dashed arguments for proxy commands
If you have a GIT_PROXY_COMMAND configured, we will run it
with the host/port on the command-line. If a URL contains a
mischievous host like "--foo", we don't know how the proxy
command may handle it. It's likely to break, but it may also
do something dangerous and unwanted (technically it could
even do something useful, but that seems unlikely).

We should err on the side of caution and reject this before
we even run the command.

The hostname check matches the one we do in a similar
circumstance for ssh. The port check is not present for ssh,
but there it's not necessary because the syntax is "-p
<port>", and there's no ambiguity on the parsing side.

It's not clear whether you can actually get a negative port
to the proxy here or not. Doing:

  git fetch git://remote:-1234/repo.git

keeps the "-1234" as part of the hostname, with the default
port of 9418. But it's a good idea to keep this check close
to the point of running the command to make it clear that
there's no way to circumvent it (and at worst it serves as a
belt-and-suspenders check).

Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28 15:52:18 -07:00
Jeff King
ca386ee177 t5532: use write_script
The recent cleanup in b7cbbff switched t5532's use of
backticks to $(). This matches our normal shell style, which
is good. But it also breaks the test on Solaris, where
/bin/sh does not understand $().

Our normal shell style assumes a modern-ish shell which
knows about $(). However, some tests create small helper
scripts and just write "#!/bin/sh" into them. These scripts
either need to go back to using backticks, or they need to
respect $SHELL_PATH. The easiest way to do the latter is to
use write_script.

While we're at it, let's also stick the script creation
inside a test_expect block (our usual style), and split the
perl snippet into its own script (to prevent quoting
madness).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 11:46:43 -07:00
Elia Pinto
b7cbbffb85 t/t5532-fetch-proxy.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.

The backquoted form is the traditional method for command
substitution, and is supported by POSIX.  However, all but the
simplest uses become complicated quickly.  In particular, embedded
command substitutions and/or the use of double quotes require
careful escaping with the backslash character.

The patch was generated by:

for _f in $(find . -name "*.sh")
do
	perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg'  "${_f}"
done

and then carefully proof-read.

Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-04 13:42:40 -08:00
Junio C Hamano
7096b6486e tests: enclose $PERL_PATH in double quotes
Otherwise it will be split at a space after "Program" when it is set
to "\\Program Files\perl" or something silly like that.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-24 21:56:13 -07:00
Vincent van Ravesteijn
a3428205e6 t: Replace 'perl' by $PERL_PATH
GIT-BUILD-OPTIONS defines PERL_PATH to be used in the test suite. Only a
few tests already actually use this variable when perl is needed. The
other test just call 'perl' and it might happen that the wrong perl
interpreter is used.

This becomes problematic on Windows, when the perl interpreter that is
compiled and installed on the Windows system is used, because this perl
interpreter might introduce some unexpected LF->CRLF conversions.

This patch makes sure that $PERL_PATH is used everywhere in the test suite
and that the correct perl interpreter is used.

Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-12 09:30:41 -07:00
Jeff King
c7730e6f5f test core.gitproxy configuration
This is just a basic sanity test to see whether
core.gitproxy works at all. Until now, we were not testing
anywhere.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-18 12:52:00 -07:00