If receive a request like:
git-upload-pack /foo.git\0host=localhost
we mark the offset of the NUL byte as "len", and then log
the bytes after the NUL with a "%.*s" placeholder, using
"pktlen - len" as the length, and "line + len + 1" as the
start of the string.
This is off-by-one, since the start of the string skips past
the separating NUL byte, but the adjusted length includes
it. Fortunately this doesn't actually read past the end of
the buffer, since "%.*s" will stop when it hits a NUL. And
regardless of what is in the buffer, packet_read() will
always add an extra NUL terminator for safety.
As an aside, the git.git client sends an extra NUL after a
"host" field, too, so we'd generally hit that one first, not
the one added by packet_read(). You can see this in the test
output which reports 15 bytes, even though the string has
only 14 bytes of visible data. But the point is that even a
client sending unusual data could not get us to read past
the end of the buffer, so this is purely a cosmetic fix.
Reported-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we start git-daemon for our tests, we send its stderr
log stream to a named pipe. We synchronously read the first
line to make sure that the daemon started, and then dump the
rest to descriptor 4. This is handy for debugging test
output with "--verbose", but the tests themselves can't
access the log data.
Let's dump the log into a file, as well, so that future
tests can check the log. There are a few subtleties worth
calling out here:
- we'll continue to send output to descriptor 4 for
viewing/debugging, which would imply swapping out "cat"
for "tee". But we want to ensure that there's no
buffering, and "tee" doesn't have a standard way to
ask for that. So we'll use a shell loop around "read"
and "printf" instead. That ensures that after a request
has been served, the matching log entries will have made
it to the file.
- the existing first-line shell loop used read/echo. We'll
switch to consistently using "read -r" and "printf" to
relay data as faithfully as possible.
- we open the logfile for append, rather than just output.
That makes it OK for tests to truncate the logfile
without restarting the daemon (the OS will atomically
seek to the end of the file when outputting each line).
That allows tests to look at the log without worrying
about pollution from earlier tests.
Helped-by: Lucas Werkmeister <mail@lucaswerkmeister.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We don't actually care about the clone operation here; we
just want to know if we were able to actually contact the
remote repository. Using ls-remote does that more
efficiently, and without us having to worry about managing
the tmp.git directory.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A recently introduced regression caused a segfault at clone time on
case-insensitive filesystems when filenames differing only in case are
present. This bug has already been fixed (repository: pre-initialize
hash algo pointer, 2018-01-18), but it's not the first time similar
problems have arisen. Therefore, introduce a test to catch this case and
protect against future regressions.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 89a70b80 ("t0302 & t3900: add forgotten quotes", 2018-01-03), quotes
were added to protect against spaces in $HOME. In the test_when_finished
command, two files are deleted which must be quoted individually.
[jc: with \$HOME in the test_when_finished command quoted, as
pointed out by j6t].
Signed-off-by: Beat Bolli <dev+git@drbeat.li>
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git merge -s recursive" did not correctly abort when the index is
dirty, if the merged tree happened to be the same as the current
HEAD, which has been fixed.
* ew/empty-merge-with-dirty-index:
merge-recursive: do not look at the index during recursive merge
"git rebase -p -X<option>" did not propagate the option properly
down to underlying merge strategy backend.
* js/fix-merge-arg-quoting-in-rebase-p:
rebase -p: fix quoting when calling `git merge`
Git's assumption that all path lists are colon-separated is not only
wrong on Windows, it is not even an assumption that is compatible with
POSIX.
In the interest of time, let's not try to fix this properly but simply
work around the obvious breakage on Windows, where the MSYS2 Bash used
by Git for Windows to interpret the Git's Unix shell scripts will
automagically convert path lists in the environment to
semicolon-separated lists of Windows paths (with drive letter and the
corresponding colon and all that jazz).
In other words, we simply look whether there is a semicolon in
GITPERLLIB and split by semicolons if found instead of colons. This is
not fool-proof, of course, as the path list could consist of a single
path. But that is not the case in Git for Windows' test suite, there are
always two paths in GITPERLLIB.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When merging another branch into ours, if their tree is the same as
the common ancestor's, we can declare that our tree represents the
result of three-way merge. In such a case, the recursive merge
backend incorrectly used to create a commit out of our index, even
when the index has changes.
A recent fix attempted to prevent this by adding a comparison
between "our" tree and the index, but forgot that this check must be
restricted only to the outermost merge. Inner merges performed by
the recursive backend across merge bases are by definition made from
scratch without having any local changes added to the index. The
call to index_has_changes() during an inner merge is working on the
index that has no relation to the merge being performed, preventing
legitimate merges from getting carried out.
Fix it by limiting the check to the outermost merge.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git merge -s recursive" did not correctly abort when the index is
dirty, if the merged tree happened to be the same as the current
HEAD, which has been fixed.
* ew/empty-merge-with-dirty-index:
merge-recursive: avoid incorporating uncommitted changes in a merge
move index_has_changes() from builtin/am.c to merge.c for reuse
t6044: recursive can silently incorporate dirty changes in a merge
It has been reported that strategy arguments are not passed to `git
merge` correctly when rebasing interactively, preserving merges.
The reason is that the strategy arguments are already quoted, and then
quoted again.
This fixes https://github.com/git-for-windows/git/issues/1321
Original-patch-by: Kim Gybels <kgybels@infogroep.be>
Also-reported-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The apache config used by tests was updated to use the SetEnvIf
directive to set the Git-Protocol header in 19113a26b6 ("http: tell
server that the client understands v1", 2017-10-16).
Setting the Git-Protocol header is restricted to httpd >= 2.4, but
mod_setenvif and the SetEnvIf directive work with lower versions, at
least as far back as 2.0, according to the httpd documentation:
https://httpd.apache.org/docs/2.0/mod/mod_setenvif.html
Drop the restriction. Tested with httpd 2.2 and 2.4.
Signed-off-by: Todd Zullinger <tmz@pobox.com>
Acked-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When cleaning up files in the $HOME directory, it really makes sense to
quote the path, especially in Git's test suite, where the HOME directory
is *guaranteed* to contain spaces in its name.
It would appear that those two tests pass even without cleaning up the
files, but really more by pure chance than by design (the cleanup seems
not actually to be necessary).
However, if anybody would have a left-over `trash/` directory in Git's
`t/` directory, these tests would fail, because they would all of a
sudden try to delete that directory, but without the `-r` (recursive)
flag. That is how this issue was found.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is totally legitimate to clone Git's source code anywhere, including
into, say, directories whose name (or the name of its absolute path)
contains spaces.
However, a couple of tests failed to anticipate this, for lack of
quoting (or in one instance, for failure to expect more than one space
in the absolute path of the TEST_DIRECTORY). This can be easily verified
by calling these commands in your current clone:
git clone . with\ spaces
cd with\ spaces
make -j15 test
Let's fix this.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git describe" was taught to dig trees deeper to find a
<commit-ish>:<path> that refers to a given blob object.
* sb/describe-blob:
builtin/describe.c: describe a blob
builtin/describe.c: factor out describe_commit
builtin/describe.c: print debug statements earlier
builtin/describe.c: rename `oid` to avoid variable shadowing
revision.h: introduce blob/tree walking in order of the commits
list-objects.c: factor out traverse_trees_and_blobs
t6120: fix typo in test name
"git merge" learned to pay attention to merge.verifySignatures
configuration variable and pretend as if '--verify-signatures'
option was given from the command line.
* hi/merge-verify-sig-config:
t5573, t7612: clean up after unexpected success of 'pull' and 'merge'
t: add tests for pull --verify-signatures
merge: add config option for verifySignatures
"git svn" has been updated to strip CRs in the commit messages, as
recent versions of Subversion rejects them.
* ew/svn-crlf:
git-svn: convert CRLF to LF in commit message to SVN
Introduce a helper to simplify code to parse a common pattern that
expects either "--key" or "--key=<something>".
* cc/skip-to-optional-val:
t4045: reindent to make helpers readable
diff: add tests for --relative without optional prefix value
diff: use skip_to_optional_arg_default() in parsing --relative
diff: use skip_to_optional_arg_default()
diff: use skip_to_optional_arg()
index-pack: use skip_to_optional_arg()
git-compat-util: introduce skip_to_optional_arg()
"git clone --shared" to borrow from a (secondary) worktree did not
work, even though "git clone --local" did. Both are now accepted.
* es/clone-shared-worktree:
clone: support 'clone --shared' from a worktree
A few structures and variables that are implementation details of
the decorate API have been renamed and then the API got documented
better.
* jt/decorate-api:
decorate: clean up and document API
"git worktree add" learned to run the post-checkout hook, just like
"git checkout" does, after the initial checkout.
* es/worktree-checkout-hook:
worktree: invoke post-checkout hook (unless --no-checkout)
With a configuration variable rebase.abbreviateCommands set,
"git rebase -i" produces the todo list with a single-letter
command names.
* lb/rebase-i-short-command-names:
sequencer.c: drop 'const' from function return type
t3404: add test case for abbreviated commands
rebase -i: learn to abbreviate command names
rebase -i -x: add exec commands via the rebase--helper
rebase -i: update functions to use a flags parameter
rebase -i: replace reference to sha1 with oid
rebase -i: refactor transform_todo_ids
rebase -i: set commit to null in exec commands
Documentation: use preferred name for the 'todo list' script
Documentation: move rebase.* configs to new file
The "safe crlf" check incorrectly triggered for contents that does
not use CRLF as line endings, which has been corrected.
* tb/check-crlf-for-safe-crlf:
t0027: Adapt the new MIX tests to Windows
convert: tighten the safe autocrlf handling
In preparation for implementing narrow/partial clone, the object
walking machinery has been taught a way to tell it to "filter" some
objects from enumeration.
* jh/object-filtering:
rev-list: support --no-filter argument
list-objects-filter-options: support --no-filter
list-objects-filter-options: fix 'keword' typo in comment
pack-objects: add list-objects filtering
rev-list: add list-objects filtering support
list-objects: filter objects in traverse_commit_list
oidset: add iterator methods to oidset
oidmap: add oidmap iterator methods
dir: allow exclusions from blob in addition to file
--update-shelve can now be specified multiple times on the
command-line, to update multiple shelved changelists in a single
submit.
This then means that a git patch series can be mirrored to a
sequence of shelved changelists, and (relatively easily) kept in
sync as changes are made in git.
Note that Perforce does not really support overlapping shelved
changelists where one change touches the files modified by
another. Trying to do this will result in merge conflicts.
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test scripts count number of lines in an output and check it againt
its expectation. fb3340a6 ("test-lib: introduce test_line_count to
measure files", 2010-10-31) introduced a helper to show a failure in
such a test in a more readable way than comparing `wc -l` output with
a number.
Besides, on some platforms, "$(wc -l <file)" is padded with leading
whitespace on the left, so
test "$(wc -l <file)" = 4
would not work (most notably on macosX); the users of test_line_count
helper would not suffer from such a portability glitch.
Add a check in check-non-portable-shell.pl to find '"' between
`wc -l` and '=' and hint the user about test_line_count().
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Reviewed-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ew/empty-merge-with-dirty-index-maint:
merge-recursive: avoid incorporating uncommitted changes in a merge
move index_has_changes() from builtin/am.c to merge.c for reuse
t6044: recursive can silently incorporate dirty changes in a merge
builtin/merge.c contains this important requirement for merge strategies:
/*
* At this point, we need a real merge. No matter what strategy
* we use, it would operate on the index, possibly affecting the
* working tree, and when resolved cleanly, have the desired
* tree in the index -- this means that the index must be in
* sync with the head commit. The strategies are responsible
* to ensure this.
*/
merge-recursive does not do this check directly, instead it relies on
unpack_trees() to do it. However, merge_trees() has a special check for
the merge branch exactly matching the merge base; when it detects that
situation, it returns early without calling unpack_trees(), because it
knows that the HEAD commit already has the correct result. Unfortunately,
it didn't check that the index matched HEAD, so after it returned, the
outer logic ended up creating a merge commit that included something
other than HEAD.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The recursive merge strategy has some special handling when the tree for
the merge branch exactly matches the merge base, but that code path is
missing checks for the index having changes relative to HEAD. Add a
testcase covering this scenario.
Reported-by: Andreas Krey <a.krey@gmx.de>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I was compiling origin/master today with DEVELOPER compiler flags
and was greeted by:
t/helper/test-lazy-init-name-hash.c: In function ‘cmd_main’:
t/helper/test-lazy-init-name-hash.c:172:5: error: ‘nr_threads_used’ may be used uninitilized in this function [-Werror=maybe-uninitialized]
printf("avg [size %8d] [single %f] %c [multi %f %d]\n",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
nr,
~~~
(double)avg_single/1000000000,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(avg_single < avg_multi ? '<' : '>'),
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(double)avg_multi/1000000000,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
nr_threads_used);
~~~~~~~~~~~~~~~~
t/helper/test-lazy-init-name-hash.c:115:6: note: ‘nr_threads_used’ was declared here
int nr_threads_used;
^~~~~~~~~~~~~~~
I do not see how we can arrive at that line without having `nr_threads_used`
initialized, as we'd have `count > 1` (which asserts that we ran the
loop above at least once, such that it *should* be initialized).
Just clear the variable at the beginning of the function to squelch
the warning.
Signed-off-by: Stefan Beller <sbeller@google.com>
Acked-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous steps added test_when_finished to tests that run 'git
pull' or 'git merge' with expectation of success, so that the test
after them can start from a known state even when their 'git pull'
invocation unexpectedly fails. However, tests that run 'git pull'
or 'git merge' expecting it not to succeed forgot to protect later
tests the same way---if they unexpectedly succeed, the test after
them would start from an unexpected state.
Reset and checkout the initial commit after all these tests, whether
they expect their invocations to succeed or fail.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ancient part of codebase still shows dots after an abbreviated
object name just to show that it is not a full object name, but
these ellipses are confusing to people who newly discovered Git
who are used to seeing abbreviated object names and find them
confusing with the range syntax.
* ar/unconfuse-three-dots:
t2020: test variations that matter
t4013: test new output from diff --abbrev --raw
diff: diff_aligned_abbrev: remove ellipsis after abbreviated SHA-1 value
t4013: prepare for upcoming "diff --raw --abbrev" output format change
checkout: describe_detached_head: remove ellipsis after committish
print_sha1_ellipsis: introduce helper
Documentation: user-manual: limit usage of ellipsis
Documentation: revisions: fix typo: "three dot" ---> "three-dot" (in line with "two-dot").
The way "git worktree add" determines what branch to create from
where and checkout in the new worktree has been updated a bit.
* tg/worktree-create-tracking:
add worktree.guessRemote config option
worktree: add --guess-remote flag to add subcommand
worktree: make add <path> <branch> dwim
worktree: add --[no-]track option to the add subcommand
worktree: add can be created from any commit-ish
checkout: factor out functions to new lib file
Recent update to the submodule configuration code broke "diff-tree"
by accidentally stopping to read from the index upfront.
* bw/submodule-config-cleanup:
diff-tree: read the index so attribute checks work in bare repositories
An v2.12-era regression in pathspec match logic, which made it look
into submodule tree even when it is not desired, has been fixed.
* bw/pathspec-match-submodule-boundary:
pathspec: only match across submodule boundaries when requested
"git diff" learned a variant of the "--patience" algorithm, to
which the user can specify which 'unique' line to be used as
anchoring points.
* jt/diff-anchored-patience:
diff: support anchoring line(s)
Historically, the diff machinery for rename detection had a
hardcoded limit of 32k paths; this is being lifted to allow users
trade cycles with a (possibly) easier to read result.
* en/rename-progress:
diffcore-rename: make diff-tree -l0 mean -l<large>
sequencer: show rename progress during cherry picks
diff: remove silent clamp of renameLimit
progress: fix progress meters when dealing with lots of work
sequencer: warn when internal merge may be suboptimal due to renameLimit
