We already have a perfectly fine prereq to tell us whether it is safe to
use symlinks. So let's use it.
This fixes the performance tests in Git for Windows' SDK, where symlinks
are not really available ([*1*]). This is not an issue with Git for
Windows itself because it configures core.symlinks=false in its system
config. However, the system config is disabled for the performance
tests, for obvious reasons: we want them to be independent of the
vagaries of any local configuration.
Footnote *1*: Windows has symbolic links. Git for Windows disables them
by default, though (for example: in standard setups, non-admins lack the
privilege to create symbolic links). For details, see
https://github.com/git-for-windows/git/wiki/Symbolic-Links
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recent update to Git LFS broke "git p4" by changing the output from
its "lfs pointer" subcommand.
* ls/p4-lfs:
git-p4: fix Git LFS pointer parsing
travis-ci: express Linux/OS X dependency versions more clearly
travis-ci: update Git-LFS and P4 to the latest version
Move from unsigned char[20] to struct object_id continues.
* bc/object-id:
match-trees: convert several leaf functions to use struct object_id
tree-walk: convert tree_entry_extract() to use struct object_id
struct name_entry: use struct object_id instead of unsigned char sha1[20]
match-trees: convert shift_tree() and shift_tree_by() to use object_id
test-match-trees: convert to use struct object_id
sha1-name: introduce a get_oid() function
"git rebase -m" could be asked to rebase an entire branch starting
from the root, but failed by assuming that there always is a parent
commit to the first commit on the branch.
* bw/rebase-merge-entire-branch:
git-rebase--merge: don't include absent parent as a base
HTTP transport clients learned to throw extra HTTP headers at the
server, specified via http.extraHeader configuration variable.
* js/http-custom-headers:
http: support sending custom HTTP headers
The test scripts for "git p4" (but not "git p4" implementation
itself) has been updated so that they would work even on a system
where the installed version of Python is python 3.
* ld/p4-test-py3:
git-p4 tests: time_in_seconds should use $PYTHON_PATH
git-p4 tests: work with python3 as well as python2
git-p4 tests: cd to / before running python
"git describe --contains" often made a hard-to-justify choice of
tag to give name to a given commit, because it tried to come up
with a name with smallest number of hops from a tag, causing an old
commit whose close descendant that is recently tagged were not
described with respect to an old tag but with a newer tag. It did
not help that its computation of "hop" count was further tweaked to
penalize being on a side branch of a merge. The logic has been
updated to favor using the tag with the oldest tagger date, which
is a lot easier to explain to the end users: "We describe a commit
in terms of the (chronologically) oldest tag that contains the
commit."
* js/name-rev-use-oldest-ref:
name-rev: include taggerdate in considering the best name
"git p4" learned to record P4 jobs in Git commit that imports from
the history in Perforce.
* jd/p4-jobs-in-commit:
git-p4: add P4 jobs to git commit message
git-p4: clean-up code style in tests
The test runs `chmod 0` on a file to test a case where Git fails to
read it, but that would not work if it is run as root.
Reported-by: Jan Keromnes <janx@linux.com>
Fix-proposed-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The last test added to 't5510-fetch' in 0898c96281 (fetch: release
pack files before garbage-collecting, 2016-01-13) may sporadically
trigger following error message from the test harness:
rm: cannot remove 'trash directory.t5510-fetch/auto-gc/.git': Directory not empty
The test in question forces an auto-gc, which, if the system supports
it, runs in the background by default, and occasionally takes long
enough for the test to finish and for 'test_done' to start
housekeeping. This can lead to the test's 'git gc --auto' in the
background and 'test_done's 'rm -rf $trash' in the foreground racing
each other to create and delete files and directories. It might just
happen that 'git gc' re-creates a directory that 'rm -rf' already
visited and removed, which ultimately triggers the above error.
Disable detaching the auto-gc process to ensure that it finishes
before the test can continue, thus avoiding this racy situation.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unify internal logic between "git tag -v" and "git verify-tag"
commands by making one directly call into the other.
* st/verify-tag:
tag -v: verify directly rather than exec-ing verify-tag
verify-tag: move tag verification code to tag.c
verify-tag: prepare verify_tag for libification
verify-tag: update variable name and type
t7030: test verifying multiple tags
builtin/verify-tag.c: ignore SIGPIPE in gpg-interface
"git push" from a corrupt repository that attempts to push a large
number of refs deadlocked; the thread to relay rejection notices
for these ref updates blocked on writing them to the main thread,
after the main thread at the receiving end notices that the push
failed and decides not to read these notices and return a failure.
* jk/push-client-deadlock-fix:
t5504: drop sigpipe=ok from push tests
fetch-pack: isolate sigpipe in demuxer thread
send-pack: isolate sigpipe in demuxer thread
run-command: teach async threads to ignore SIGPIPE
send-pack: close demux pipe before finishing async process
"git mv old new" did not adjust the path for a submodule that lives
as a subdirectory inside old/ directory correctly.
* sb/mv-submodule-fix:
mv: allow moving nested submodules
Sources to many test helper binaries (and the generated helpers)
have been moved to t/helper/ subdirectory to reduce clutter at the
top level of the tree.
* nd/test-helpers:
test helpers: move test-* to t/helper/ subdirectory
Makefile: clean *.o files we create
0492eb48 (t9824: fix broken &&-chain in a subshell, 2016-04-24)
revealed a test that was broken from the beginning, as it expected a
wrong size. The expected size of the file under test is 39
bytes. The test checked that the size is 13 bytes, but this was not
noticed because it was breaking the &&-chain.
Fix the reference value to make the test pass.
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git LFS 1.2.0 removed a preamble from the output of the 'git lfs pointer'
command [1] which broke the parsing of this output. Adjust the parser
to support the old and the new format.
Please note that this patch slightly changes the second return parameter
from a list of LF terminated strings to a single string that contains
a number of LF characters.
[1] da2935d9a7
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Helped-by: Sebastian Schuberth <sschuberth@gmail.com>
Helped-by: Ben Woosley <ben.woosley@gmail.com>
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We introduce a way to send custom HTTP headers with all requests.
This allows us, for example, to send an extra token from build agents
for temporary access to private repositories. (This is the use case that
triggered this patch.)
This feature can be used like this:
git -c http.extraheader='Secret: sssh!' fetch $URL $REF
Note that `curl_easy_setopt(..., CURLOPT_HTTPHEADER, ...)` takes only
a single list, overriding any previous call. This means we have to
collect _all_ of the headers we want to use into a single list, and
feed it to cURL in one shot. Since we already unconditionally set a
"pragma" header when initializing the curl handles, we can add our new
headers to that list.
For callers which override the default header list (like probe_rpc),
we provide `http_copy_default_headers()` so they can do the same
trick.
Big thanks to Jeff King and Junio Hamano for their outstanding help and
patient reviews.
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>
The time_in_seconds script should use $PYTHON_PATH, rather than
just hard-coded python, so that users can override which version
gets used, as is done for other python invocations.
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update the git-p4 tests so that they work with both
Python2 and Python3.
We have to be explicit about the difference between
Unicode text strings (Python3 default) and raw binary
strings which will be exchanged with Perforce.
Additionally, print always takes parentheses in Python3.
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The python one-liner for getting the current time prints out
error messages if the current directory is deleted while it is
running if using python3.
Avoid these messages by switching to "/" before running it.
This problem does not arise if using python2.
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When creating a shallow clone of a repository with submodules, the depth
argument does not influence the submodules, i.e. the submodules are done
as non-shallow clones. It is unclear what the best default is for the
depth of submodules of a shallow clone, so we need to have the possibility
to do all kinds of combinations:
* shallow super project with shallow submodules
e.g. build bots starting always from scratch. They want to transmit
the least amount of network data as well as using the least amount
of space on their hard drive.
* shallow super project with unshallow submodules
e.g. The superproject is just there to track a collection of repositories
and it is not important to have the relationship between the repositories
intact. However the history of the individual submodules matter.
* unshallow super project with shallow submodules
e.g. The superproject is the actual project and the submodule is a
library which is rarely touched.
The new switch to select submodules to be shallow or unshallow supports
all of these three cases.
It is easy to transition from the first to the second case by just
unshallowing the submodules (`git submodule foreach git fetch
--unshallow`), but it is not possible to transition from the second to the
first case (as we would have already transmitted the non shallow over
the network). That is why we want to make the first case the default in
case of a shallow super project. This leads to the inconvenience in the
second case with the shallow super project and unshallow submodules,
as you need to pass `--no-shallow-submodules`.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git submodule" reports the paths of submodules the command
recurses into, but this was incorrect when the command was not run
from the root level of the superproject.
* sb/submodule-path-misc-bugs:
t7407: make expectation as clear as possible
submodule update: test recursive path reporting from subdirectory
submodule update: align reporting path for custom command execution
submodule status: correct path handling in recursive submodules
submodule update --init: correct path handling in recursive submodules
submodule foreach: correct path display in recursive submodules
When "git merge" notices that the merge can be resolved purely at
the tree level (without having to merge blobs) and the resulting
tree happens to already exist in the object store, it forgot to
update the index, which lead to an inconsistent state for later
operations.
* en/merge-trivial-fix:
builtin/merge.c: fix a bug with trivial merges
t7605: add a testcase demonstrating a bug with trivial merges
"merge-octopus" strategy did not ensure that the index is clean
when merge begins.
* en/merge-octopus-fix:
merge-octopus: abort if index does not match HEAD
t6044: new merge testcases for when index doesn't match HEAD
Code restructuring around the "refs" area to prepare for pluggable
refs backends.
* dt/pre-refs-backend: (24 commits)
refs: on symref reflog expire, lock symref not referrent
refs: move resolve_ref_unsafe into common code
show_head_ref(): check the result of resolve_ref_namespace()
check_aliased_update(): check that dst_name is non-NULL
checkout_paths(): remove unneeded flag variable
cmd_merge(): remove unneeded flag variable
fsck_head_link(): remove unneeded flag variable
read_raw_ref(): change flags parameter to unsigned int
files-backend: inline resolve_ref_1() into resolve_ref_unsafe()
read_raw_ref(): manage own scratch space
files-backend: break out ref reading
resolve_ref_1(): eliminate local variable "bad_name"
resolve_ref_1(): reorder code
resolve_ref_1(): eliminate local variable
resolve_ref_unsafe(): ensure flags is always set
resolve_ref_unsafe(): use for loop to count up to MAXDEPTH
resolve_missing_loose_ref(): simplify semantics
t1430: improve test coverage of deletion of badly-named refs
t1430: test for-each-ref in the presence of badly-named refs
t1430: don't rely on symbolic-ref for creating broken symrefs
...
"git rerere" can encounter two or more files with the same conflict
signature that have to be resolved in different ways, but there was
no way to record these separate resolutions.
* jc/rerere-multi:
rerere: adjust 'forget' to multi-variant world order
rerere: split code to call ll_merge() further
rerere: move code related to "forget" together
rerere: gc and clear
rerere: do use multiple variants
t4200: rerere a merge with two identical conflicts
rerere: allow multiple variants to exist
rerere: delay the recording of preimage
rerere: handle leftover rr-cache/$ID directory and postimage files
rerere: scan $GIT_DIR/rr-cache/$ID when instantiating a rerere_id
rerere: split conflict ID further
Every yes/no question in difftool/mergetool scripts has slightly
different form, and none of them is consistent with the form git
itself uses.
Make the form of all the questions consistent with the form used
by git.
Reviewed-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Nikola Forró <nforro@redhat.com>
Acked-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Absent this fix, attempts to rebase an orphan branch using "rebase -m"
fails with:
$ git rebase -m ORPHAN_TARGET_BASE
First, rewinding head to replay your work on top of it...
fatal: Could not parse object 'ORPHAN_ROOT_SHA^'
Unknown exit code (128) from command: git-merge-recursive ORPHAN_ROOT_SHA^ -- HEAD ORPHAN_ROOT_SHA
To fix, this will only include the rebase root's parent as a base if it exists,
so that in cases of rebasing an orphan branch, it is a simple two-way merge.
Note the default rebase behavior does not fail:
$ git rebase ORPHAN_TARGET_BASE
First, rewinding head to replay your work on top of it...
Applying: ORPHAN_ROOT_COMMIT_MSG
Using index info to reconstruct a base tree...
A few tests were expecting the old behaviour to forbid rebasing such
a history with "rebase -m", which now need to expect them to succeed.
Signed-off-by: Ben Woosley <ben.woosley@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git commit" misbehaved in a few minor ways when an empty message
is given via -m '', all of which has been corrected.
* ad/commit-have-m-option:
commit: do not ignore an empty message given by -m ''
commit: --amend -m '' silently fails to wipe message
A partial rewrite of "git submodule" in the 2.7 timeframe changed
the way the gitdir: pointer in the submodules point at the real
repository location to use absolute paths by accident. This has
been corrected.
* sb/submodule-helper-clone-regression-fix:
submodule--helper, module_clone: catch fprintf failure
submodule--helper: do not borrow absolute_path() result for too long
submodule--helper, module_clone: always operate on absolute paths
submodule--helper clone: create the submodule path just once
submodule--helper: fix potential NULL-dereference
recursive submodules: test for relative paths
To get the 'value' from '--option=value', test-lib.sh parses said
option running 'expr' with a regexp. This involves a subshell, an
external process, and a lot of non-alphanumeric characters in the
regexp.
Use a much simpler POSIX-defined shell parameter expansion instead to
do the same.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We most likely want the oldest tag that contained the commit to be
reported. So let's remember the taggerdate, and make it more important
than anything else when choosing the best name for a given commit.
Suggested by Linus Torvalds.
Note that we need to update t9903 because it tested for the old behavior
(which preferred the description "b1~1" over "tags/t2~1").
We might want to introduce a --heed-taggerdate option, and make the new
behavior dependent on that, if it turns out that some scripts rely on the
old name-rev method.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous commit said:
We could add the same option to "git pull" and have it passed
through to underlying "git merge". I do not have a fundamental
opposition against such a feature, but this commit does not do
so and instead leaves it as low-hanging fruit for others,
because such a "two project merge" would be done after fetching
the other project into some location in the working tree of an
existing project and making sure how well they fit together, it
is sufficient to allow a local merge without such an option
pass-through from "git pull" to "git merge".
Prepare a patch to make it a reality, just in case it is needed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because "test_commit five" creates a commit and point it with a tag
'five', doing so on a branch whose name is 'five' will later result
in an 'ambiguous refs' warning. Even though it is harmless because
all the later references are for the tag, there is no reason for the
branch to be called 'five'. Give it a name that describes its
purpose more clearly, i.e. "newroot".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were added by 8bf4bec (add "ok=sigpipe" to
test_must_fail and use it to fix flaky tests, 2015-11-27)
because we would racily die via SIGPIPE when the pack was
rejected by the other side.
But since we have recently de-flaked send-pack, we should be
able to tighten up these tests (including re-adding the
expected output checks).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When migrating from Perforce to git the information about P4 jobs
associated with P4 changelists is lost.
Having these jobs listed on messages of related git commits enables smooth
migration for projects that take advantage of e.g. JIRA integration
(which uses jobs on Perforce side and parses commit messages on git side).
The jobs are added to the message in the same format as is expected when
migrating in the reverse direction.
Signed-off-by: Jan Durovec <jan.durovec@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Preliminary clean-up of testing libraries for git-p4.
* spaces added to both sides of () in function definitions in lib-git-p4
* tab indentation added to git-p4 tests when <<- redirection is used
Signed-off-by: Jan Durovec <jan.durovec@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When directories are moved using `git mv` all files in the directory
have been just moved, but no further action was taken on them. This
was done by assigning the mode = WORKING_DIRECTORY to the files
inside a moved directory.
submodules however need to update their link to the git directory as
well as updates to the .gitmodules file. By removing the condition of
`mode != INDEX` (the remaining modes are BOTH and WORKING_DIRECTORY) for
the required submodule actions, we perform these for submodules in a
moved directory.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The verify-tag command supports multiple tag names to verify, but
existing tests only test for invocation with a single tag.
Add a test invoking it with multiple tags.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Santiago Torres <santiago@nyu.edu>
Reviewed-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A change back in version 2.7 to "git branch" broke display of a
symbolic ref in a non-standard place in the refs/ hierarchy (we
expect symbolic refs to appear in refs/remotes/*/HEAD to point at
the primary branch the remote has, and as .git/HEAD to point at the
branch we locally checked out).
* jk/branch-shortening-funny-symrefs:
branch: fix shortening of non-remote symrefs
When "git worktree" feature is in use, "git branch -m" renamed a
branch that is checked out in another worktree without adjusting
the HEAD symbolic ref for the worktree.
* ky/branch-m-worktree:
set_worktree_head_symref(): fix error message
branch -m: update all per-worktree HEADs
refs: add a new function set_worktree_head_symref
