"cherry-pick" had a small leak in its error codepath.
* fc/sequencer-plug-leak:
sequencer: avoid leaking message buffer when refusing to create an empty commit
sequencer: remove useless indentation
Logic used by git-send-email to suppress cc mishandled names like "A
U. Thor" <author@example.xz>, where the human readable part needs to
be quoted (the user input may not have the double quotes around the
name, and comparison was done between quoted and unquoted strings).
It also mishandled names that need RFC2047 quoting.
* mt/send-email-cc-match-fix:
send-email: sanitize author when writing From line
send-email: add test for duplicate utf8 name
test-send-email: test for pre-sanitized self name
t/send-email: test suppress-cc=self with non-ascii
t/send-email: add test with quoted sender
send-email: make --suppress-cc=self sanitize input
t/send-email: test suppress-cc=self on cccmd
send-email: fix suppress-cc=self on cccmd
t/send-email.sh: add test for suppress-cc=self
Some shells do not understand the one-line construct, and instead need
FOO=bar &&
export FOO
Detect this in the test-lint target.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The == operator as an alias to = is not POSIX. This doesn't actually
matter for the execution of the script, because it only runs when the
shell is bash. However, it trips up test-lint, so it's nicer to use
the standard form.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The path of the file to be locked is held in lock_file::filename,
which is a fixed-length buffer of length PATH_MAX. This buffer is
also (temporarily) used to hold the path of the lock file, which is
the path of the file being locked plus ".lock". Because of this, the
path of the file being locked must be less than (PATH_MAX - 5)
characters long (5 chars are needed for ".lock" and one character for
the NUL terminator).
On entry into lock_file(), the path length was only verified to be
less than PATH_MAX characters, not less than (PATH_MAX - 5)
characters.
When and if resolve_symlink() is called, then that function is
correctly told to treat the buffer as (PATH_MAX - 5) characters long.
This part is correct. However:
* If LOCK_NODEREF was specified, then resolve_symlink() is never
called.
* If resolve_symlink() is called but the path is not a symlink, then
the length check is never applied.
So it is possible for a path with length (PATH_MAX - 5 <= len <
PATH_MAX) to make it through the checks. When ".lock" is strcat()ted
to such a path, the lock_file::filename buffer is overflowed.
Fix the problem by adding a check when entering lock_file() that the
original path is less than (PATH_MAX - 5) characters.
[jc: with independent development by Peff]
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The default similarity index of 50% is documented in gitdiffcore(7)
but it is worth also mentioning it in the description of the
-M/--find-renames option.
Signed-off-by: Fraser Tweedale <frase@frase.id.au>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This script was added in 36e5e70 (Start deprecating "git-command" in
favor of "git command", 2007-06-30) with the intent of aiding the
transition away from dashed forms.
It has already been used to help the transision and served its
purpose, and is no longer very useful for follow-up work, because
the majority of remaining matches it finds are false positives.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rs/empty-archive:
t5004: resurrect original empty tar archive test
t5004: avoid using tar for checking emptiness of archive
Conflicts:
t/t5004-archive-corner-cases.sh
"gitweb" forgot to clear a global variable $search_regexp upon each
request, mistakenly carrying over the previous search to a new one
when used as a persistent CGI.
* cm/gitweb-project-list-persistent-cgi-fix:
gitweb: fix problem causing erroneous project list
"git log -c --follow $path" segfaulted upon hitting the commit that
renamed the $path being followed.
* cb/log-follow-with-combined:
fix segfault with git log -c --follow
When a reflog notation is used for implicit "current branch", we did
not say which branch, and worse said "branch ''".
* rr/die-on-missing-upstream:
sha1_name: fix error message for @{<N>}, @{<date>}
sha1_name: fix error message for @{u}
Since commit 00b347d (git-config: do not complain about duplicate
entries, 2012-10-23), "git config --get" does not exit with an error if
there are multiple values for the specified key but instead returns the
last value. Update the documentation to reflect this.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
One test in t1512 that expects a failure incorrectly passed. The
test prepares a commit whose object name begins with ten "0"s, and
also prepares a tag that points at the commit. The object name of
the tag also begins with ten "0"s. There is no other commit-ish
object in the repository whose name begins with such a prefix.
Ideally, in such a repository:
$ git rev-parse --verify 0000000000^{commit}
should yield that commit. If 0000000000 is taken as the commit
0000000000e4f, peeling it to a commmit yields that commit itself,
and if 0000000000 is taken as the tag 0000000000f8f, peeling it to a
commit also yields the same commit, so in that twisted sense, the
extended SHA-1 expression 0000000000^{commit} is unambigous. The
test that expects a failure is to check the above command.
The reason the test expects a failure is that we did not implement
such a "unification" of two candidate objects. What we did (or at
least, meant to) implement was to recognise that a commit-ish is
required to expand 0000000000, and notice that there are two succh
commit-ish, and diagnose the request as ambiguous.
However, there was a bug in the logic to check the candidate
objects. When the code saw 0000000000f8f (a tag) that shared the
shortened prefix (ten "0"s), it tried to make sure that the tag is a
commit-ish by looking at the tag object. Because it incorrectly
used lookup_object() when the tag has not been parsed, however, we
incorrectly declared that the tag is _not_ a commit-ish, leaving the
sole commit in the repository, 0000000000e4f, that has the required
prefix as "unique match", causing the test to pass when it shouldn't.
This fixes the logic to inspect the type of the object a tag refers
to, to make the test that is expected to fail correctly fail.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The earliest iteration of this test script used a magic string
110282 as the common prefix for ambiguous object names, but the
final edition switched the common prefix to 0000000000 (10 "0"s).
Unfortunately, instances of the original prefix were left in the
comments and a few tests. Replace them with the correct constants.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mac OS X does not like to write(2) more than INT_MAX number of
bytes; work it around by chopping write(2) into smaller pieces.
* fc/macos-x-clipped-write:
compate/clipped-write.c: large write(2) fails on Mac OS X/XNU
Newer MacOS X encourages the programs to compile and link with their
CommonCrypto, not with OpenSSL.
* da/darwin:
imap-send: eliminate HMAC deprecation warnings on Mac OS X
cache.h: eliminate SHA-1 deprecation warnings on Mac OS X
Makefile: add support for Apple CommonCrypto facility
Makefile: fix default regex settings on Darwin
The configure option to disable threading is '--disable-pthreads',
not '--without-pthreads'.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cloning with "git clone --depth N" while fetch.fsckobjects (or
transfer.fsckobjects) is set to true did not tell the cut-off points
of the shallow history to the process that validates the objects and
the history received, causing the validation to fail.
* 'nd/clone-connectivity-shortcut' (early part):
fetch-pack: prepare updated shallow file before fetching the pack
clone: let the user know when check_everything_connected is run
* rr/push-head:
push: make push.default = current use resolved HEAD
push: fail early with detached HEAD and current
push: factor out the detached HEAD error message